fix: recover auto cap from protected working sets

[brndnmtthws]

Summary

Fix auto target sizing so cargo-hold can recover when its selected cap is repeatedly proven unattainable by artifacts that GC deliberately preserves, while retaining the v1.3.5 protection against arbitrary target-directory bloat ratcheting the cap upward.

User Impact

Fallback cache restores no longer remain trapped in a destructive loop that repeatedly removes useful artifacts without ever learning an attainable cap. Confirmed policy-protected working sets can recover to a realistic cap, while unexplained or removable bloat remains unable to drive unbounded growth.

Root Cause

Sizing finals and cap overages were stored in independently bounded histories, allowing an ancient healthy sample to outlive newer over-cap runs. Healthy-only final-to-final growth also provided no useful signal after a metadata-only cold start, and every over-cap result was rejected without recording whether the excess was actually reclaimable under the active preservation policy.

Fix

• Replace the independent metric arrays with one bounded chronological window of complete auto-cap run outcomes.
• Record recognized protected, eligible, and retained artifact bytes; deliberately preserved executable bytes; and unrecognized bytes.
• Treat only repeated over-cap runs whose measured policy-protected floor exceeds the cap as proof that the cap is unattainable.
• Recover to the lower-median confirmed policy floor plus the existing 2 GiB cold-start cushion. Eligible and unrecognized bytes never enter that recovery target.
• Keep normal cap changes constrained by the existing per-run growth and shrink clamps, and require repeated evidence so isolated spikes do not become permanent increases.
• Emit diagnostics explaining the selected sample source, ignored over-cap runs, policy floor, and whether an overage can trigger recovery.
• Move to metadata v6 and discard incompatible cached metadata instead of adding legacy migration or poisoned-state heuristics.
• Add synthetic multi-run Phoenix lifecycle coverage plus adversarial 256 GiB bloat, isolated-spike, stable-run, executable-preservation, chronological-window, and fresh-metadata tests.

Validation

• cargo +nightly fmt --check
• cargo check --all-targets
• cargo clippy --all-targets -- -D warnings
• cargo nextest run — 135 passed
• cargo test --doc — 4 passed

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.