ci(release): adopt the verified release flow

[jimisola]

What & Why

Migrates this repo to the reworked org release flow in
reqstool/.github#66.

The old arrangement stopped at a draft. A human clicked Publish, and only then did
the publish workflows run — so everything that verified a release ran after it was already
public, and a failure meant a bad release was live.

Now the release is created as a prerelease and promoted only once everything that can
fail has succeeded. A prerelease rather than a draft because a draft is invisible to the
verification too (/releases/tags/<tag> 404s unauthenticated), while a prerelease is
readable by exact tag and still excluded from /releases/latest.

prepare  ->  lint + build  ->  [approval]  tag  ->  ...  ->  publish  ->  promote

The confirmation step is an environment approval on the job that tags, reached after
lint and build are already green — so a reviewer approves something verified rather than a
version string.

The version is no longer typed by hand. It is auto-detected from Conventional Commits;
passing one that disagrees requires force, which is the guard that catches "meant 0.3.0,
typed 0.2.0" before it becomes a tag. prerelease: rc cuts a release candidate — verified
exactly like a release, but never promoted to latest.

dry-run defaults to on: dispatching Release shows the resolved version, the generated
notes, and the raw commits they came from, without tagging or creating anything.

See RELEASING.md for the
full flow.

Author checklist

• actionlint clean
• Conventional Commit title, DCO sign-off
• No behaviour removed without a replacement

Test Plan

Merge order matters: this cannot merge before reqstool/.github#66. The workflows it
calls do not exist on main until that lands.

After merging:

1. Dispatch Release with dry-run left on. Confirm the job summary shows the resolved
   version, the notes, and the commit list — and that no tag or release exists afterwards.
2. Dispatch with prerelease: rc and dry-run off. Confirm it pauses for approval, then
   produces a prerelease with its artifacts attached, and that /releases/latest is
   unchanged.
3. Only then cut a real release with prerelease: none.

Note on pinning

Workflows are referenced at @main rather than a commit SHA, because the SHA does not exist
until #66 is squash-merged. Re-pinning to that SHA is a follow-up.

Repo-specific

• build.yml gains ref, so the flow can re-run it against the tag it just created — that build is what gives the artifacts their version, since hatch-vcs reads it from git. It also gains artifact-name: the flow builds twice in one run, and upload-artifact rejects a duplicate name.
• Its checkout now fetches tags. With hatch-vcs a shallow clone computes the wrong version rather than failing.
• publish_pypi_test.yml → publish-dev-to-testpypi.yml, now calling the shared workflow. Behaviour unchanged: every push to main still lands on Test PyPI as a .devN build.
• Suggested pilot repo — smallest blast radius of the nine. Worth running steps 1–3 here first.