feat(ci): advance v1 automatically once the gate is green on main

Nothing moved v1 when main advanced, so a merged change was inert
until someone remembered to retag by hand — it happened on 2026-09-22
(PR #25 merged, v1 stayed on the previous release) and was only caught
because a person asked whether the tag had moved.

Option 1 from gitdan-actions#27 (automate it) over option 2 (fail loud
while it lags): a `release-tag` job, gated with `needs: selftest` so a
broken build never reaches it, force-moves v1 to the pushed commit
using the run's built-in GITHUB_TOKEN. If that token turns out not to
have write access, the push fails and the job goes red in the Actions
UI — a loud failure either way, not the silent one this replaces.
Whether the token actually has write access here is unverified short
of a real merge; that merge is the next step for this branch.

README's Versioning section documented the old manual step as a
deliberate decision "never something a merge does by itself" — that
claim is now false, so it's rewritten to describe the automated job
and keeps the manual command as the recovery path for when the job
can't push.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UkSjXXtU6JYcN2vPntWhfb

README.md

@@ -634,13 +634,20 @@ entry, another permission — is a `v2`, not a `v1` move. Everything else moves
 `v1`: correctness fixes, new optional inputs, and anything internal to
 `scripts/`.
 
-**Moving the tag is a release step, and it is the operator's.** Merging to
-`main` ships nothing to anybody. `v1` is a lightweight tag and does not follow
-a branch, so until it is re-pointed every consumer keeps fetching the commit it
-already named, whatever `main` now says. The gap is deliberate: re-pointing
-`v1` changes what another repository's CI executes on its next run, so it is a
-decision taken once, knowingly, after the merge — never something a merge does
-by itself.
+**Moving the tag is automatic, gated on the same build that gates a PR.** A
+`release-tag` job in `.gitea/workflows/ci.yaml` runs on every push to `main`,
+`needs: selftest`, and force-moves `v1` to that commit once selftest
+succeeds — a broken build never reaches it, so `v1` can't advance onto one.
+It pushes with the run's built-in `GITHUB_TOKEN`; if that token turns out not
+to have write access, the push step fails and the job goes red in the Actions
+UI. That's a loud failure, not the silent one this replaced: `v1` stays put,
+and nobody has to notice on their own that it lagged.
+
+This used to be a manual step, treated as a deliberate release decision taken
+once, knowingly, after the merge — in practice it was still forgotten
+(gitdan-actions#27): PR #25 merged to `main` and `v1` stayed on the previous
+release until someone asked whether it had moved. The manual form below is
+now the recovery path, for when the automated job can't push:
 
 ```bash
 git fetch origin
@@ -651,9 +658,8 @@ git ls-remote --tags origin v1     # must equal git rev-parse origin/main
 
 **Downstream** are emowheel, which pins `cargo-cache@v1` and
 `cargo-cache-publish@v1` across its CI workflow, and zemyna, migrating to the
-same pin. Both pick a move up on their next run with no change on their side,
-which is the whole point of the moving pointer and also the reason the move is
-not automatic.
+same pin. Both pick a move up automatically on their next run with no change
+on their side, which is the whole point of the moving pointer.
 
 ---