fsck: handle packs removed by concurrent repacks - #2221

"git multi-pack-index verify" (which "git fsck" spawns when MIDX support
is enabled) walks the midx's packs, closing and reopening each by name
as it checks object offsets.  A concurrent "git repack" that unlinks a
redundant pack in that window makes the reopen fail, and verify reports
"failed to load pack in position N", "failed to load pack entry for
oid[N]", or "failed to load pack-index for packfile ..." -- all of which
read like midx corruption even when the objects are still available
in a replacement pack.

A missing referenced ".pack" can be a symptom of concurrent maintenance,
but does not establish whether its objects are available elsewhere.
Add a one-time hint suggesting a retry after maintenance completes,
while keeping the existing per-failure diagnostics and nonzero status.

To provoke it, "git multi-pack-index write" a repo with several packs
and run "git multi-pack-index verify" while "git repack -adq" loops in
the background; verify occasionally fails with one of the messages
above, now followed by the retry hint.

Assisted-by: Claude Opus 4.8
Signed-off-by: Elijah Newren <newren@gmail.com>

MIDX verification closes packs between object groups and later reopens
them by name.  A concurrent repack can remove one in that interval,
causing verification to fail on an otherwise benign race.

When the referenced packs fit within an estimated fd budget, pre-open
them and skip the verifier's per-pack closes during the walk.  Geometric
repacking is expected to keep pack counts small enough for this to be
useful.  Larger MIDX chains retain the close-as-we-go path and its
race-aware diagnostic.

This is best effort: find_lru_pack() ignores do_not_close, so
close_one_pack() may still reclaim descriptors under pressure.

Assisted-by: Claude Opus 4.8
Signed-off-by: Elijah Newren <newren@gmail.com>