perf(store): size the pack body cache to the working set

[rmanibus]

Summary

• packCache is bounded by total bytes rather than by a fixed count of four bodies
• The budget is eight packs' worth, which covers the working set the benchmark exercises

Holding four bodies meant the cache's real size was four times whatever a pack
weighed — and four is below the working set of an ordinary repository, which is
what made a miss matter: a miss re-reads an entire packfile to return one small
object.

Part of #458.

Measurements

check on a 50,000-file repository with two snapshots and 6 packs — the shape
the benchmark builds, and the one where its check allocation jumps to ~3 GB:

	allocation	peak RSS
main @ 051a07e	4.80 GB	266 MB
this PR	550 MB	204 MB

Both improve, because the re-read transients dominated peak as well as
cumulative allocation.

No regression where the working set already fit:

repository	main	this PR
5,000 files	141 MB peak	141 MB peak
50,000 files, 1 snapshot (4 packs)	158 MB peak	158 MB peak

Why this and not an ordering fix

The issue as I filed it guessed at a scattered access pattern. Tracing showed the
opposite: check issues 127,789 lookups across 6 packs and misses 0.39% of
them against a four-pack cache. There is nothing like restore's 55% before #455.

Those 495 misses cost 4.2 GB because each one re-reads ~9 MB. At six packs the
same trace misses six times. The order was already good; the cache was smaller
than the order needs.

The budget is deliberately larger than what it replaces. Shrinking it was
measured and is worse — at 32 MB the same check peaks at 251 MB against 167 MB,
because the transfers a smaller cache forces cost more than the residency it
saves (#440 comment).

Note on the regression test

TestPackStore_DoesNotRereadPacksWhenTheWorkingSetFits asserts on bytes
transferred, not on whole-pack count. My first version asserted on the count
and passed even with a one-pack budget: since #452, a too-small cache does not
do more whole-pack transfers, it does more ranged reads, so the count barely
moves while the traffic triples.

The fixture also writes more than packPromoteAfter objects per pack. With fewer,
a pack is never cached at all — every read stays a ranged read — and the test
measures promotion behaviour rather than the cache.

Both directions verified: it passes at the shipped budget and fails at a one-pack
budget (3.1 MB read against 806 KB of packs).

Verification

env GOCACHE=/tmp/cloudstic-gocache go test -race -count=1 ./internal/... .

env GOCACHE=/tmp/cloudstic-gocache GOLANGCI_LINT_CACHE=/tmp/cloudstic-golangci-lint golangci-lint run ./internal/storelayer/...

Both pass; lint reports 0 issues. check verifies an identical 10,993 objects
with 0 errors before and after.

One figure I cannot fully account for

At 5,000 files, allocation drops from 115 MB to 3.5 MB while peak RSS is
unchanged and the object count verified is identical. The direction is expected —
that repository's packs now stay cached — but the magnitude is larger than the
pack sizes explain, so treat it as unexplained rather than as a headline. The
50,000-file figures above are the ones I would rely on.

[codecov]

Codecov Report

❌ Patch coverage is 94.44444% with 2 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
internal/storelayer/packbodycache.go	94.11%	1 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!