Budget crash-loop recovery by volume capacity

[hamzamerzic]

Summary

• admit a crash-loop re-clone only when the volume can hold the larger of the live and baked platform trees plus a capacity-relative reserve
• reclaim closed Chromium caches first, then prune only older redundant crash-loop recoveries; the newest recovery point is never a deletion candidate
• replace the three-tree count limit with a byte budget and recheck real free space after the atomic quarantine move before bootstrap may clone
• expose current volume capacity with a bounded, cached top-level /data breakdown and the last crash-loop admission/retention result

Safety boundaries

Situation	Behavior
enough free space	quarantine the live tree, preserve it as the newest recovery, then bootstrap
headroom depends on an existing recovery	keep it until the live tree becomes the new recovery, then prune the now-older copy and recheck free space
cache and older recoveries cannot create headroom	leave the live tree in place and serve the baked floor
post-move pruning or sizing fails	preserve the new recovery, serve the baked floor, and retry the capacity check on the next boot
normal operation	refresh the bounded breakdown after readiness and with the existing hourly browser-profile sweep; health reads never walk /data

The default clone reserve matches the small-volume critical floor (5% with a 32 MiB minimum), and older crash-loop history is capped at one quarter of volume capacity up to 2 GiB. Operators can raise the clone estimate or tune both byte budgets without introducing a provider-specific mode.

This builds on the active-profile and hard-quota guarantees from #226 and the capacity-derived browser budget from #635. It completes the remaining persistent-volume admission, recovery-retention, and operator-diagnostics work in #160 without adding recovery archive formats or another daemon.

Verification

• simulated a 512 MiB volume with 33 MiB free, a 133 MiB live platform, a 95 MiB recovery, and 95 MiB of reclaimable browser cache
• proved the order is cache first, then only the recovery that becomes redundant after the atomic move
• proved an unsafe restore fails before moving the live tree or deleting the only recovery
• proved the newest recovery keeps a local commit, dirty tracked work, untracked files, executable modes, and symlinks even when it exceeds the history budget
• proved the larger baked tree controls admission and an operator estimate cannot lower that measured requirement
• 45 focused volume, browser-profile, resource-pressure, and supervisor tests passed
• 79 fast platform contract tests passed; shell syntax, Python compilation, and canonical diff checks passed

Closes #160