Merge pull request 'docs: clear PR #28's docs-drift catalog entries' (#31) from chore/docs-catalog-2026-09-23 into main

README.md

@@ -648,12 +648,12 @@ built-in `GITHUB_TOKEN`:
   comparison. Otherwise it runs the same shellcheck and selftests against the
   tip and moves `v1` there only if they pass.
 
-Both jobs request `contents: write` on the run's built-in token, but whether
-that actually grants a push to this repo is **unobserved until the first
-merge** — the grant is capped by the repo's and owner's maximum token
-permissions, and branch/tag protections on `v1` can't be read without admin
-access. A rejected push is a red job, not a silent no-op, so the first merge
-after this lands is the real test.
+Both jobs request `contents: write` on the run's built-in token, and that
+grant is now **verified**: PR #28's own merge ran `release-tag` successfully
+and moved `v1` to that merge's commit. The grant is still capped by the
+repo's and owner's maximum token permissions, and branch/tag protections on
+`v1` can't be read without admin access. A rejected push is a red job, not a
+silent no-op.
 
 So `v1` trails a green `main` by at most about one sweep interval plus one
 selftest run, and **a `main` that fails its gate shows up as a red sweep on every

scripts/release-v1-selftest.sh

@@ -136,8 +136,8 @@ ok "server rejection with v1 unmoved: red, not a lost lease"
 
 echo
 echo "=== 9. the merge job defers on a moved tip; the next sweep catches up ==="
-# The stranded trace: C1's job runs after C2 merged and defers, C2's job was
-# cancelled in the concurrency group, and merges stop.
+# The stranded trace: C1's job runs after C2 merged and defers — a run that
+# deferred and left no newer run behind it — and merges stop.
 fresh
 before=$(origin_v1)
 c1=$(commit_to_main)