Split out of #78 rather than folded into PR #50, which fixes one call site.

Repo.storage_call(repo, :get_object, [sha]) reads loose objects only — it is a single File.read of objects/ab/cdef… on the filesystem backend. ObjectResolver.read/2 (and now read_raw/2) is the pack-aware read: packs first, loose on miss.

#78 was one call site that assumed the former meant “read an object”: ReceivePack.build_external_resolver/1. On any repacked repository every lookup missed and git push was rejected outright. The same assumption may well be sitting in other call sites, and it is invisible until a repository gets packed — which is exactly what Maintenance.repack/1 and #228 do on purpose.

What to do

Enumerate every storage_call(_, :get_object, _) and every direct Object.read/2 in lib/, and for each decide whether it genuinely wants “the loose copy” or actually wants “the object”. Anything in the second category should go through ObjectResolver.

Call sites that legitimately want loose-only — Maintenance‘s repack enumeration, for instance, which is specifically about finding loose objects to pack — should be left alone and commented to say so, so the next reader doesn’t have to re-derive the distinction.

Why it is worth doing now

The storage layout everything is moving toward (server-side repack #228, keeping received packs instead of exploding them, the S3 migration) is the layout that exposes this class of bug. Each instance fails only after a repo is packed, so they will surface one at a time in production rather than in tests, the way #78 did.

Not in scope

Behaviour changes beyond routing reads through the pack-aware path.