Harden Runtime release evidence and CI trust boundary

[ashishki]

What changed

• add a repository-level verify-committed-evidence command that binds the exact v0.1.0 manifest SHA-256, source revision, recorded environment, lifecycle, zero-cost stub boundary, backpressure state, and 20/20 artifact-integrity result
• add positive, tamper/reseal, and machine-readable CLI regression tests
• make the documented reproduction write reports and artifacts only below a fresh mktemp directory instead of overwriting tracked release evidence
• run committed-evidence verification explicitly in CI
• pin checkout and setup-python to verified 40-character revisions, restrict the workflow token to contents: read, and disable persisted checkout credentials
• update the release documentation and changelog with the post-release verification boundary

Why

The existing generic manifest verifier checked declared report bytes, but CI did not bind the committed v0.1.0 content address or its published semantics. The reproduction command also targeted the tracked canonical report path, so a reviewer following it would dirty and replace the release evidence files.

Impact

Reviewers can now verify the immutable release boundary with one machine-readable command. New reproduction output remains separate from the canonical snapshot. Runtime behavior and the historical v0.1.0 evidence bytes are unchanged.

Validation

• ruff check src tests
• ruff format --check src tests
• full PostgreSQL/Redis suite: 100 passed
• committed verifier: sha256:07442b769fad42a1664cc3adc7a11d73cb2041ceb61f65e402087e096d5b12ed, 20 submitted jobs, 20 valid artifacts
• generic manifest verifier passed
• clean wheel build/install, pip check, console help, and installed-wheel committed verifier passed
• wheel SHA-256: 75a26ad0140329ba70e1fc08c72db9a959017f254bab9bee558804d35c4e4596
• scoped Docker project and volumes removed after validation