[Devops] Remove the real-PyPI priming dispatch path once all packages are primed

[lowlydba]

Context

release-publish.yaml's workflow_dispatch gained a target: pypi option in PR #638, so #653's manual priming work has a real-PyPI path, not just Test PyPI. It always publishes a synthetic <on-disk-version>.dev0 (never the real release version) through the same pypi-release-<package> environment the automated release path already uses -- no separate approval-gated environment, workflow_dispatch already requires repo write access to trigger, which is gate enough for a disposable priming publish.

This is a bootstrapping tool for priming Trusted Publishers past PyPI's pending-registration rate limit (~3 at a time, applies independently to pypi.org and test.pypi.org), not a permanent fixture. Once every package has a converted (non-pending) Trusted Publisher for the v2.0 launch, there's no more legitimate use for a manual dispatch path straight to production PyPI: it's standing attack surface (a compromised or careless dispatch can put a .dev0 on the real index) with no ongoing purpose after priming is done.

Task

• Remove the target: pypi option from release-publish.yaml's workflow_dispatch once all 12 packages are primed on real PyPI (drop the target input entirely, since test-pypi would be the only remaining choice).
• Keep the Test PyPI dispatch path; it has no production blast radius and stays useful for ongoing pipeline verification.
• Fix docs/versioning.md's release-flow table (currently line 60), which still describes real-PyPI dispatches as requiring a pypi-dispatch-<package> approval environment. That gate doesn't exist: dispatch reuses pypi-release-<package>, with no separate approval-gated environment.

Parent: #653