refactor(compact): derive the cache boundary from the shared tracker

[OsherElhadad]

Partially addresses #47. Read the scope note below — this does not claim to fix the pin-budget fail-open.

What this changes

/compact fell through to apply's legacy store-backed prevLen, which the chat path had already moved off (#43). So this endpoint kept two properties the chat path had shed:

• concurrent turns of one session race on a read-then-deferred-write of the boundary;
• the boundary lives in a store key (cg:len:) competing for the pin budget, rather than in memory.

Switched to apply.BodyOpts with the proxy's existing modes.Tracker — the same one the chat path uses.

Why it matters: measurement, not a live cache regression

The chat path was already on the tracker, so production was fine. /compact is the offline replay/eval endpoint, so a boundary derived differently from production means eval measures a different component than the one that ships.

That is the same class of divergence as the context window this handler used to hard-code as unknown — visible a few lines above in the same function — and it went unnoticed for the same reason: both are silent. This repo has now hit that class three times (the hard-coded window, internal/modelinfo never resolving a window at all, and this), which is why it's worth naming rather than just patching.

Scope note — what I am NOT claiming

#47's pin-budget fail-open is not fixed and stays open. I tried to reproduce it and could not: cg:len: survived 40 frozen decisions from distinct sessions plus 40 ordinary puts at MaxEntries: 20 (pin cap 10). The boundary came back intact on both the legacy and tracker paths.

I am not going to assert a fix for a failure I cannot demonstrate. This change removes /compact's exposure to that failure by keeping the boundary out of the store entirely — but that is a consequence, not the point, and the eviction question itself is unresolved.

No test, deliberately

The two paths are behaviourally identical on the boundary they derive, so a test asserting turn-to-turn behaviour passes either way. I wrote one, watched it pass with the tracker removed, and deleted it rather than keep a test that proves nothing and would give a future reader false confidence.

What would be worth testing is the eviction scenario itself — but that belongs in #47, once someone can actually trigger it.

Gates

go build -tags cg_skeleton ./... · go test -tags cg_skeleton ./... · go test -race ./proxy/... ./apply/... · gofmt -l — all clean.