release.sh: batch preflight, defer push-after-publish, modern build

[petemoore]

Summary

Restructures release.sh so that:

• All preflight problems are reported in one batch instead of fail-fast, so a botched environment can be fixed in a single pass instead of N script invocations.
• git push happens AFTER PyPI and Docker Hub publishes succeed. A publish failure now leaves the remote untouched, making recovery a matter of git reset --hard HEAD~1 && git tag -d v<version> instead of having a half-released tag on GitHub.
• Build uses python -m build (PEP-517 frontend) instead of the deprecated setup.py sdist / bdist_wheel, with twine check run on the built dists before upload to catch metadata problems (bad README rendering, invalid classifiers, etc.) locally.
• Drops the misleading --real flag. It only redirected PyPI between test and real; Docker Hub and GitHub were always published to the real registries, so it wasn't a true dry-run. Documented an end-to-end test-PyPI one-liner in RELEASING.md for the rare case it's wanted.

Companion RELEASING.md documents prerequisites, the workflow, pre-publish verification, and the recovery procedure.

New preflight checks

Check	Why
docker, pass, gpg, python3 on PATH	Catches missing tools before any destructive work
Docker daemon reachable + docker buildx available	Avoids "tag pushed, then docker push fails"
GPG secret key present	git tag -s would otherwise fail mid-script
pass entries exist (community-tc/secret-values.yml with tc-admin-release-pypi-password: line, plus hub.docker.com/taskclusterbot)	Avoids reaching the password prompt with no password to paste
Branch is literally main	Old SHA-only check passed on a feature branch sitting at the same commit as main

Existing checks (working tree clean, local HEAD == remote main HEAD, version regex on both old and new, tag-doesn't-exist locally + remotely, not in a virtualenv, signed tag) all preserved.

Comparison and out-of-scope items

This came out of a comparison with json-e/release.sh. Items deliberately not included in this PR:

• Towncrier-style changelog automation — worth doing separately as it's a process change, not just a script change.
• Auto-detect git remote — adds the requirement of having a named remote, with no real benefit; the hardcoded SSH URL is fine.
• Idempotent re-run on partial failure — preflight should make partial failures rare, and reusing a release number after a partial failure has its own correctness problems.
• Hermetic Docker-based release host — requires shipping pass + GPG key into a container, and docker buildx --push from inside Docker is awkward.

Test plan

• Read the new release.sh and RELEASING.md for sanity
• Verify CI passes (pytest + flake8 on the unchanged Python code)
• On the next real release, the preflight phase exercises end-to-end

🤖 Generated with Claude Code