Harden PyPI and GitHub release trust

[ChelseaKR]

Summary

• Verifies signed tags from reviewed main, builds the exact commit, and rechecks tag identity before PyPI and GitHub publication.
• pins the maintainer SSH signer in the repository
• documents the release-boundary change in the changelog

Validation

• portfolio conformance release_workflow: PASS
• actionlint: PASS
• zizmor offline, medium+ findings: none
• YAML parse and git diff --check: PASS

[ChelseaKR]

Drain-prep review 2026-07-31: MERGE-READY (pending un-draft — owner: @ChelseaKR)

Reviewed the full 252-line diff. This is a sound hardening of the release control plane:

• Trigger moves from tag-push to workflow_dispatch from reviewed main — the verify job asserts GITHUB_REF == refs/heads/main and head == origin/main before touching the tag.
• Closes the REL-08 identity gap the old workflow honestly documented: .github/allowed_signers pins the maintainer SSH key and git verify-tag now checks the signer, not just signature presence.
• Ancestry check (merge-base --is-ancestor against origin/main), strict vX.Y.Z regex, and immutable tag-object re-verification immediately before both the PyPI publish and the GitHub Release create — good TOCTOU hygiene; --verify-tag retained.
• All downstream jobs build the exact resolved release commit via ref:, and the publish jobs stay least-privilege.

All 16 checks green. Two conscious trade-offs to confirm when un-drafting: (1) releases now require a manual dispatch — no tag-push automation; (2) a signer-key rotation now requires a repo commit. Both seem intended. Also see #103 (pypi-publish 1.14.1) which touches the same publish step — carry the newer pin in whichever lands second. Advances #80, though PyPI Trusted Publisher registration remains a user action.

🤖 Generated with Claude Code