EPIC: automate the xorq release flow (#2283-#2287)

[mesejo]

Why this epic exists

#2272 fixed five defects in CONTRIBUTING.md's Release Flow. Four of the five were found
by cutting v0.4.1, not by reading the guide. That is the evidence this flow needs machine
checks rather than better prose.

This epic tracks the five tickets that replace the hand-typed release steps with a validated,
still-human-supervised flow. Every publish continues to wait on a named human; what changes
is that the human approves a validated release instead of typing the steps that have
already gone wrong.

Spec: .scratch/automating-release.md (written against main @ 844bb30, v0.4.2).

Target flow

scripts/release.sh patch        # steps 1-6, local, ends at the release commit  (#2286)
git push -u origin release-X    # human keystroke -> fires ci-pre-release       (#2285)
  precheck job (no gate)        # validates; posts a PR warning if the version is burned
  publish job (gated)           # waits for a named reviewer, then TestPyPI     (#2284)
open PR, review, squash-merge   # human
git tag / git push origin vX    # human, manual per CONTRIBUTING
publish the drafter draft at vX # human, UI -> fires ci-release -> PyPI

Human gates kept deliberately: opening the PR, approving the deployment, merging, tagging,
publishing the GitHub release.

Tickets

• Generated changelog section lands in the right place with no hand-editing #2283 — Generated changelog section lands in the right place with no hand-editing
• Pre-release publishing requires a named human and can only run from a release branch #2284 — Pre-release publishing requires a named human and can only run from a release branch
• Pushing a release branch starts the pre-release publish, and it waits for approval #2285 — Pushing a release branch starts the pre-release publish, and it waits for approval
• One command takes a maintainer from clean main to a reviewed release commit #2286 — One command takes a maintainer from clean main to a reviewed release commit
• The release guide describes the flow that actually exists, including how to recover #2287 — The release guide describes the flow that actually exists, including how to recover

Dependency order

Two independent tracks converge on the documentation ticket:

#2283 (changelog header) ──> #2286 (release.sh) ──┐
                                                  ├──> #2287 (docs)
#2284 (environment gate) ──> #2285 (workflow)  ───┘

#2283 and #2284 can start immediately and in parallel. #2287 lands last because it
documents both tracks.

Definition of done

• A maintainer cuts a release with one local command plus a push, and approves one deployment.
• No step in CONTRIBUTING.md instructs anyone to dispatch a workflow by hand, move a
  changelog block by hand, or wait for tests that do not exist.
• A pre-release publish cannot happen from a non-release-* ref, and cannot happen without a
  named reviewer.
• A failed or retried release is recoverable by a documented procedure that states what is
  reversible and what is permanently spent.

Constraints that span the tickets

• The index's trusted publisher is bound to the pre-release workflow's filename and the
  pre-release environment's name. Neither may be renamed without reconfiguring the
  publisher on the index side.
• A filename published to an index can never be reused, even after deletion. Validation must
  fail before upload, not after.