[forhappy]

Source-history fsck can return a clean result when a lifetime head becomes corrupt while an original source body is being verified. The deterministic regression on #597 fires that mutation and observes Ok(()) before this change.

Capture source-head CAS tokens and the pruning floor with the authenticated source history. Recheck them after original-body verification and retain the capture through the later data/Git checks. Valid movement asks the caller to retry; invalid control bytes fail validation. Head revalidation uses bounded GETs with 16 concurrent requests, preserving both provider ETag/version tokens without rescanning immutable history or rereading source bodies.

Stacked on #597. Capsule, checkpoint, catalog and lifetime encodings remain unchanged. GC and foreground lookups do not acquire the new maintenance revalidation workload. The user-owned advisor plan and both large-file audit reports are excluded.

Validation:

• Baseline regression reproduced the false clean result on fix(catalog): retain compacted capture sources #597.
• 12 storage-only metadata tests and 65 CLI fsck/GC/history tests pass, including corruption during a source read and pruning after checker construction.
• Strict release Clippy passes for all targets of crab-metadata, crab-storage and crab-write.
• The committed source matches every input hash guarded during the final checks; no dependency or lockfile changes.

The parent stack has a stale rusqlite dependency-policy expectation. Its one-entry alignment is awaiting the explicit approval required by AGENTS.md; no check has been disabled or expected record changed here. Exact-source live concurrency/fault qualification and combined-stack 10 GiB qualification remain release gates. This draft is not ready to merge.

Is this the best fix? Keeping control identity at the existing source-verification boundary covers both construction and later checks, avoids a new global writer bottleneck, and adds no reader leases or catalog fallback.