Auto-recover corrupt packfiles in packfile maintenance

[tyrielv]

Independent change, based on master. Related to #2048 (both stabilize the same corrupt-packfile scenario) but has no code dependency on it. For maximum robustness, #2048 (which bounds git output) ideally lands first so recovery can't OOM on a very noisy stderr mid-recovery, but the two can merge in either order.

Summary

When a packfile in the shared object cache is corrupt/truncated (e.g. from a past disk-full event), git multi-pack-index write/verify fails with could not load pack N. The existing self-heal only deletes+rewrites the multi-pack-index (MIDX), which does not fix the underlying pack — the rewrite re-scans the same bad pack and keeps failing, so the corruption recurs indefinitely.

Change

PackfileMaintenanceStep routes write/verify failures through a recovery path. When git reports a pack-load failure:

• Detection (always runs, even with recovery disabled): verifies each pack with git verify-pack and reports every unreadable pack via telemetry (Operation=FoundCorruptPack). The N in could not load pack N is an internal MIDX position, not a filename, so per-pack verification is how we find the actual bad file.
• Removal (gated — see kill switch): deletes each corrupt pack's files (.pack/.idx/.keep/.rev; Operation=DeletedCorruptPack), then deletes+regenerates the MIDX from the packs that remain (fast path, no full repack). Missing objects are re-fetched on demand.
• Corrupt prefetch pack (special case): prefetch packs are incremental/ordered by timestamp, so a corrupt one invalidates every later prefetch pack too. Recovery removes the corrupt prefetch pack and every later prefetch pack (Operation=DeletedHealthyPrefetchPack for the healthy ones removed purely due to ordering), then requests a prefetch (via a callback GitMaintenanceScheduler wires to a PrefetchStep, only when using a cache server) to re-download them and rebuild the commit-graph.

Kill switch

The destructive pack removal is gated by a new git config gvfs.enable-packfile-recovery (default true). When false, GVFS still detects and reports corrupt packs (FoundCorruptPack → CorruptPackRecoverySkipped) but deletes nothing and requests no prefetch; the non-destructive MIDX rewrite still runs, so behavior degrades to today's. This is a field kill switch — no redeploy needed if the destructive path ever misbehaves.

Telemetry

Distinct, queryable Operation values so rollout can be watched: FoundCorruptPack (even when disabled), CorruptPackRecoverySkipped, DeletedCorruptPack, DeletedHealthyPrefetchPack, PrefetchRestoreUnavailable.

Tests

• A verify failure reporting a pack-load error removes the corrupt pack and rewrites the MIDX from the remaining good packs (recovery enabled).
• With recovery disabled, the same failure still verifies each pack and reports the corrupt one but deletes nothing.
• A corrupt prefetch pack removes it and every later prefetch pack, keeps the earlier healthy one, and requests a prefetch.

Full unit suite: 885 passed, 0 failed (11 pre-existing native-hook skips). The pre-existing PackfileMaintenanceRewriteOnBadVerify (empty-stderr verify failure → MIDX rewrite only, no pack detection) is unchanged.

Follow-up

A functional test that corrupts a real pack and asserts the mount self-heals (rather than looping) is tracked for the streaming follow-up PR.