fix: use allowAnySHA1InWant to serve orphaned commits after force-push

[jrobotham-square]

Problem

After a force-push, the old commit becomes unreachable in the local mirror. With allowReachableSHA1InWant, git upload-pack rejects requests for these commits with not our ref. For large repos (e.g. shallow clones of blox), the response can exceed the 1MB fallback buffer, causing the error to reach clients instead of falling back to upstream.

Root cause

The race condition:

1. Client receives /info/refs showing commit A on a branch
2. ensureRefsUpToDate detects stale refs and schedules a background git fetch --prune
3. The fetch runs, updating the branch ref — commit A becomes unreachable
4. Client sends POST /git-upload-pack requesting commit A
5. git upload-pack rejects: not our ref A
6. If the response exceeds 1MB, the buffered response writer has already committed, so the fallback to upstream is skipped

This is primarily triggered by rapid force-pushes to a branch that is being actively cloned (e.g. iterating on a feature branch while a blox workstation provisions).

Fix

Change uploadpack.allowReachableSHA1InWant → uploadpack.allowAnySHA1InWant in the mirror config. This lets upload-pack serve any object present in the object store, regardless of reachability.

This is safe for a caching proxy because:

• gc.auto is already disabled, so orphaned objects persist
• Clients already have access to the upstream repo
• It's actually slightly faster (skips the reachability walk)

Testing

Added TestMirrorConfigAllowsUnreachableSHA which:

1. Creates a mirror, applies configureMirror
2. Force-pushes to orphan a commit
3. Asserts upload-pack can serve the orphaned SHA

The test fails with the old config and passes with the new one.