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

• release_prod.yml and release_test.yml are replaced. The GHCR image job is unchanged in substance — it still builds from the PyPI release — but takes the version from the flow rather than github.event.release.tag_name, so it works for a dispatched release too.
• build.yml gains ref and artifact-name, and its checkout fetches tags.
• release_test.yml → publish-dev-to-testpypi.yml, now calling the shared workflow. Behaviour unchanged.

Two things deliberately not carried over

Was	Why not
sign-artifacts: true on pypa/gh-action-pypi-publish	That input does not exist. It was silently ignored. attestations — presumably what was meant — defaults to true, and the shared workflow sets it explicitly.
skip-existing: true on the real index	A re-run now fails on a version collision instead of silently succeeding. A collision on PyPI means something is wrong and should be seen. Test PyPI keeps skip-existing, where re-running after a downstream failure is routine.