Fix release publishing and add a CI token fallback

Tag builds since v0.2.2 built all artifacts but never published a release:
- tools/publish_release.sh only assembled AUTH in the GITEA_TOKEN branch; the
  ~/.git-credentials branch set CRED and then used an unbound ${AUTH[@]} under
  `set -u`, so every API call failed and the job ended "could not create or find
  release". It now sets AUTH=(-u "$CRED").
- The repo has no GITEA_TOKEN secret and the runner has no git credentials, so the
  workflow now falls back to the built-in workflow token:
  GITEA_TOKEN: ${{ secrets.GITEA_TOKEN || github.token }}.

v0.2.9 was then built and published locally with all five artifacts (portable
Linux/Windows/macOS, NSIS installer, AppImage) and the release page verified via
the API. v0.2.4-v0.2.8 remain unpublished; they are superseded by the latest.

Docs
- docs/RELEASING.md records the incident and the local-publish fallback.
- TODO gains a release-pipeline follow-up (verify CI on the next tag).
- MEMORY notes the root cause, the missing secret, and which releases exist.
- Version 0.2.10.

TODO.md

@@ -25,6 +25,16 @@ Verified via API+host credentials (2026-10-31):
       anonymous browsing/downloads redirect to login. Host admin: `REQUIRE_SIGNIN_VIEW = false`
       under `[service]` in `app.ini`, restart Gitea. Alternative: mirror downloads.
 
+## Release pipeline follow-up
+
+- [x] Fix `tools/publish_release.sh`: the `~/.git-credentials` branch never set `AUTH`,
+      so every tag build since v0.2.2 failed to publish.
+- [x] Add a `github.token` fallback in `.gitea/workflows/build.yml` (the repo has no
+      `GITEA_TOKEN` secret).
+- [ ] Verify the fallback on the next tag push produces a release automatically.
+- [ ] Optionally backfill releases for v0.2.4–v0.2.8 (their CI artifacts were not
+      retained; would need local rebuilds) or leave them superseded by the latest.
+
 ## Open Polish
 
 - [ ] Keep `%` placeholders stable in `Strings.fmt` when adding keys (positional formatting).