release: separate verification from publication and make partial publish recoverable

[pengfei-threemoonslab]

Problem

The release workflow performs expensive verification and immutable publication in one job. If PyPI publication succeeds and a later step fails, PyPI can contain an immutable version with no finalized GitHub Release or attached provenance. Re-running is not a safe recovery because the version already exists.

Test selection, parallelism, and timeout sizing are now owned by #344. This issue owns the publication transaction and recovery model.

Target design

1. A read-oriented verification job builds/validates the exact candidate and produces a content-addressed artifact handoff.
2. A publication job starts only after verification succeeds and consumes that exact handoff.
3. A draft GitHub Release exists before PyPI publication.
4. PyPI publication occurs once.
5. The draft is finalized only after all required release assets are attached and validated.

Acceptance criteria

• Verification and publication are separate jobs with an explicit artifact/digest handoff.
• Publication cannot start unless release policy: decide the approved evidence bar for pre-1.0 tags #341’s approved qualification policy, release security: bind the qualified wheel to the tagged source tree #342’s source/wheel binding, release: align test selection with CI and set a measured timeout #344’s deterministic test workload, release: add a non-publishing rehearsal path #355’s rehearsal, and release: generate and sign an SBOM for the shipped wheel only #356’s wheel-scoped SBOM controls are satisfied.
• Release concurrency is serialized across the PyPI project (not merely per tag) with cancel-in-progress: false.
• Verification has only read permissions; write and OIDC permissions are scoped to the smallest publication/signing jobs that require them.
• A draft GitHub Release is created before uv publish and finalized afterward.
• A failure after PyPI publication leaves a discoverable, recoverable draft with the authoritative assets.
• The runbook documents the exact recovery path when PyPI succeeds but release finalization fails.
• The publication step is idempotence-aware and cannot be casually retried against an existing version.

Non-goals

• Choosing the release qualification thresholds (release policy: decide the approved evidence bar for pre-1.0 tags #341).
• Test parallelism, perf-marker selection, or timeout sizing (release: align test selection with CI and set a measured timeout #344).
• General release-note/dependency cleanup (release cleanup: use CHANGELOG notes and lock release dependencies #345).