[tnull]

Allow verification on separate machines without copying every receipt back. collect asks about independently rebuilt comparisons for groups missing receipts and records those confirmations separately from rebuild evidence. Collection may retain incomplete coverage.

Publication requires every group to have a receipt or out-of-band confirmation by default. Maintainers can explicitly choose --allow-unverified for incomplete coverage. Each publication attempt preserves its destination, coverage, and override choice without overwriting earlier evidence.

Swift provenance depends only on candidate identity and artifacts, so tool upgrades and recollection can resume existing metadata commits and tags. Existing provenance with historical coverage remains compatible while candidate and artifact checks stay enforced.

Validation: all 68 tests passed, along with formatting, cargo check, and Clippy with warnings denied. Six regression tests were also confirmed to fail on the pre-fix PR commit, covering publication gating, coverage history, and Swift resume compatibility.

[benthecarman]

1. Upgrading the tool blocks Swift resume and re-runs (tools/release/src/publish/swift.rs:292). release-provenance.json now has a verification key. assert_distribution compares every byte against branches, tags and commits already pushed, and the old ones don't have that key. So a Swift publish started or finished with the old tool can't be resumed or re-run after an upgrade, and the tag can't be moved.
2. Earlier coverage records get overwritten (tools/release/src/publish.rs:156). Each publish replaces state.verification with the current run's coverage. Suppose PyPI is published with no coverage, then you re-collect and publish Maven with full coverage. The state file now says full coverage, and nothing shows that PyPI had none. The docs say coverage is "preserved in publication state", which is no longer true.
3. Re-collecting breaks Swift resume (swift.rs:292). Provenance is built from the current ledger. If a Swift publish fails after pushing the branch and draft, and you re-collect before retrying (say, to add a receipt), the new provenance won't match the commit already pushed. Recovering means fixing the branch and draft by hand.
4. Publishing now goes ahead without verification by default (publish.rs:107). Without --require-verification, a ledger with no receipts and no confirmations still uploads to PyPI, Maven or Swift. Before this PR, that case failed with "missing receipt". This is the most serious of the four, since registry uploads are permanent.

[benthecarman]

looks good on squash

[tnull]

looks good on squash

Squashed without further changes.