expand: distinguish an unresolvable marker id from a missing stash

[amiddavid]

expand.RepairToolResults substitutes Unavailable(hashID) for any marker id it cannot
resolve. That is the right behaviour for the model — it reads as "the content aged out" rather
than inviting a retry of a tool that "does not exist" — but the two reasons an id fails to
resolve are not the same event and are currently indistinguishable:

• Malformed id — the model invented or corrupted a marker id. Needs no action; it is the
  model being the model.
• Well-formed id with nothing stashed behind it — a context-guru defect. A cut was
  advertised as reversible and it was not. The stash expired, the store did not persist, or the
  key was written under a session id nothing reads.

Both currently land on the same placeholder with no counter, so the second one is invisible. The
process-wide signals that do exist measure something else: RecordExpand / wasted_tokens
counts tokens successfully re-served, and sse_expand_after_stream counts a streaming miss.
Neither can go non-zero for a broken stash — a silent no-op looks identical to "no expand calls
happened".

This is the failure mode that ran unnoticed for three iterations on #80: the refusals were found
by grepping the benchmark client's transcripts, not from any counter in this repo.

Why it was not fixed in #110

#110 is scoped to defects with selection_mode unset and every change in it is
revert-verified. This one is not a behaviour defect but an observability gap, and closing it
needs a design decision that #110 had no basis to make: what counts as a well-formed marker
id. Marker(key) wraps a store key, so classification depends on the key's shape
(ParseMarkers currently accepts anything between the delimiters). Options:

1. Validate against the hash format hashKey produces (length + alphabet). Cheap, but couples
   the classifier to the hashing scheme.
2. Treat "well-formed" as "this proxy could have minted it" — e.g. a short HMAC/prefix over the
   key — which makes the distinction exact but changes marker bytes, and marker bytes are
   prefix-cache-relevant (expand/inject.go).
3. Classify by store outcome instead of id shape: distinguish "key absent" from "key present but
   empty/expired", if the store can report that. No marker change, but it only separates the
   causes the store can see.

Option 3 looks closest to free if store.Store can distinguish absent from expired; otherwise
option 1 with the coupling documented.

Acceptance

• Two counters, split by cause, surfaced in /stats and added to the reviewed golden contract
  in proxy/stats_golden_test.go rather than loosening the assertion.
• A test per cause, each verified to fail when its subject is reverted.
• The missing-stash counter must be the one an operator can alert on, since it is the one that
  means this proxy broke a promise it made.

[amiddavid]

Fixed in 7a2ef37 on feat/sweep-adjudicator (#118). Yes — it was cheaper than this issue made it sound, and two facts settled the design question rather than a judgement call.

Option 3 separates nothing. I suggested classifying by store outcome as "closest to free" if the store could distinguish absent from expired. It cannot: store.Get returns (bytes, bool), so both causes arrive as the same false.

Option 2 rewrites every marker. Making ids self-identifying with an HMAC or prefix would be exact, but marker bytes are prefix-cache-relevant — a different marker text on a later turn is a full prefix miss (inject.go), which is a real cost to pay for a counter.

So it is option 1, shape validation — and the coupling worry that made me hesitate is closed by test rather than argued away. Every stash key that reaches a <<cg:HASH>> marker is a lowercase-hex sha256 prefix of length 16 (offload.hashKey, summarize's span stash) or 24 (extract.ContentKey, offload's state key). TestEveryMintedKeyIsWellFormed drives the real minters and asserts WellFormedID accepts what they produce, so a minter changing shape fails there.

That direction is the one that matters, and it is worth stating why: a shape check that is too narrow blames us for nothing and the model for everything, which zeroes the alertable counter — the worst possible failure for this feature. Verified by dropping 24 from the accepted lengths, which reports four minted keys as rejected, by value.

Counted at both halves of reversibility — the request-path repair and the proxy's response-side continuation loop — since a defect counted in only one would read as half as bad. That is why NoteUnresolved is exported.

Two revert-verified failures, quoted in the commit:

classification collapsed  -> expected exactly one MISSING ..., got 0
                             expected exactly one MALFORMED ..., got 2
a minted length dropped   -> ContentKey("") = "e3b0c44298fc1c149afbf4c8", which WellFormedID
                             rejects — an unresolved lookup for it would be blamed on the model
                             instead of counted as our defect

The repair-path test asserts a precondition first — that both ids actually reached the resolve path — because a fixture that never matched leaves both counts at zero, which reads identically to a working split.

Surfaced as expand_unresolved_malformed / expand_unresolved_missing. The stats golden test caught the two new fields, and they were added to the reviewed contract rather than the assertion loosened, per the rule in that file. missing is the alertable one: it means this proxy removed content, told the model it could have it back, and then could not produce it.