👷 ci(release): split into release and tag-triggered publish

[gaborbernat]

The release workflow was broken in several ways after the recent restructure: running tox r -e release locally pushed a commit and tag but nothing in CI reacted to the tag push, so no PyPI publish, no GitHub Release, and no get-virtualenv update happened. The workflow_dispatch path worked end-to-end but the release commit failed the check workflow because towncrier-generated changelog.rst was committed without running docstrfmt. The towncrier config also had name = "tox" instead of "virtualenv".

This splits the monolithic release.yaml into two workflows that converge on the same publish path regardless of how the release is triggered. 🔀 release.yaml (workflow_dispatch) now only handles Phase 1: generating the changelog, running pre-commit to ensure formatting is correct, committing, tagging, and pushing. A new publish.yaml triggers on any tag push matching *.*.* and handles Phase 2: building sdist/wheel/zipapp, publishing to PyPI via trusted publisher (OIDC), creating a GitHub Release with the zipapp attached, and updating get-virtualenv. If the publish fails, a rollback job automatically reverts everything.

The key insight is that both local (tox r -e release) and CI (workflow_dispatch) releases now produce the same artifact — a tagged commit on main — and the tag push is what triggers publishing. 🔐 PyPI publishing always happens via the trusted publisher in the release environment, never locally. The release.yaml uses GH_RELEASE_TOKEN for checkout so the push triggers publish.yaml (pushes with GITHUB_TOKEN don't trigger other workflows).