chore(supply-chain): prune the 157 exemptions the lock re-sync orphaned

[h4x0r]

Stacked on #5. Base is fix/lock-refresh-vet-and-csv, because cargo vet cannot run at all until that PR's lock re-sync lands. Retarget to main once #5 merges.

Re-syncing Cargo.lock in #5 dropped 150 package-versions from the graph. Their cargo-vet exemptions stayed behind, so cargo vet warns:

WARN Your supply-chain has unnecessary exemptions which could be relaxed or pruned.
WARN   Consider running `cargo vet prune` to prune unnecessary exemptions and imports.

This is cargo vet prune, nothing else. Pure deletion — 713 lines out, none in.

Verified, not assumed

Comparing exemption (name, version) pairs against the package-versions actually present in the lock:

exemption entries: 786 -> 629   removed=157  added=0
removed exemptions whose exact (name, version) is still in the lock: 0

Every pruned entry names a package-version that genuinely left the graph.

The name-level view is misleading here, which is worth stating because it is the obvious way to sanity-check this and it gives the wrong answer. 20 of the removed names still appear in the lock:

ahash · getrandom · http · http-body · hyper · memmap2 · memoffset · prost · prost-derive · rand · rand_chacha · rand_core · sync_wrapper · tokio-rustls · toml_datetime · toml_edit · tower · wasi · windows · winnow

Those are the duplicate-major cases from #5. The exemption removed is for the old version that left; the surviving version keeps its own entry. Checked at (name, version) granularity, the intersection is empty.

ADR-0018 compliance

All four aggregate import sets survive the prune:

[imports.bytecode-alliance]   [imports.embark]   [imports.google]   [imports.mozilla]

cargo vet prune also prunes imports, so this was worth confirming rather than trusting — count went 4 -> 4.

One inert leftover cargo-vet chose not to prune: crossbeam-epoch 0.9.18, while the lock carries 0.9.20. An exemption for an absent version grants nothing. Removing it is cargo-vet's call, not a hand edit, so it stays.

Result

Before:  Vetting Succeeded (170 fully audited, 5 partially, 628 exempted)  + 2 WARN
After:   Vetting Succeeded (170 fully audited, 5 partially, 628 exempted)

The effective exemption count is unchanged — these 157 entries were granting nothing. This removes dead policy, it does not loosen or tighten the gate.

Why this is not part of #5

#5's entire value is that a reviewer can confirm "strict subset, nothing added" at a glance. Folding 628 deleted lines of supply-chain policy into it would destroy exactly that property. Orphaned exemptions are a WARN and block nothing, so this could also simply wait.

🤖 Generated with Claude Code

[h4x0r]

CI does not run on this PR, and that is not the same as CI passing.

.github/workflows/ci.yml triggers on pull_request: branches: [main] only. This PR targets fix/lock-refresh-vet-and-csv, so the CI workflow is never dispatched — the only green checks visible here are Socket Security, which runs on every PR. Read the empty check list as "not run", not "clean".

The gates were run locally instead, on this exact branch:

gate	result
cargo build	pass
cargo test	pass, 0 failed
cargo clippy --all-targets -- -D warnings	pass
cargo fmt --check	pass
cargo vet	pass
cargo deny check	fails on RUSTSEC-2026-0222 — pre-existing on main, see #5

Retargeting this PR to main once #5 merges will dispatch the real CI run. Please do not merge on the strength of the check list as it currently reads.