Harden trusted publishing and release provenance

## Parent

- #2

## What to build

Make releases traceable and minimally privileged with trusted PyPI publishing, artifact attestations, an SBOM, dependency audits, and a documented response path for compromised or withdrawn releases.

## Acceptance criteria

- [ ] PyPI publication uses short-lived trusted credentials rather than a long-lived token.
- [ ] Wheels and source distributions carry verifiable provenance.
- [ ] Release artifacts include an SBOM and pass dependency audits.
- [ ] The release runbook documents yanking, replacement, and security notification steps.

## Blocked by

- #2
- #10
- #30

## RFC-0005 contract

Separate candidate build from publication. The production publish path must use `workflow_dispatch`, a reviewer-protected `pypi` environment, prebuilt artifact digests, and PyPI Trusted Publishing OIDC; arbitrary tag pushes cannot write to the registry. Emit provenance and `sbom_audit` evidence for M4+ releases.

Start with the RFC-0005 contract and the production publish path, paying particular attention to workflow_dispatch, the reviewer-protected pypi environment, and the blocked issues #2, #10, and #30. Done means M4+ releases use trusted publishing with prebuilt digests, emit provenance and sbom_audit evidence, include an SBOM and audit results, and have the required response runbook.

Written by the indexing model from the issue text.