fix(compaction): keep the failure record a projection is re-read through

[esengine]

Found while auditing a suspicion raised during the #8419 / #8424 work. The
suspicion (that KeepErrors content accumulates without bound) turned out to be
wrong — failure_snip.go already caps each failure at 60 lines and its own
comment acknowledges the retention is deliberate. The real defect was the
opposite: the protection expires.

Measured behaviour, before

Fixture shaped like real go test output, KeepErrors on, three folds:

Fold	Failure in projection	ToolExecution
1	yes	intact
2	yes	stripped
3	gone	—

Why

KeepErrors classifies a failure from ToolExecution, not from message text —
that change was made deliberately because text matching missed real failures. A
failing go test log opens with === RUN, so the error: / blocked: prefix
arm cannot see it.

checkpointProjectionMessages wrote the projection through ModelMessages,
which strips ToolExecution:

// Local shell metadata must never enter provider request bytes.
candidate.ToolExecution = nil

That strip is correct for a provider request. The problem is that a
projection is read twice: once as what the model is sent, and once as the input
the next compaction classifies. Only the second reading needs the host's record.
Writing the projection through the provider-boundary function collapsed those two
roles, so fold 2 saw a tool result with no failure record and text matching
nothing, folded it into the digest, and the model stopped being told.

Note this makes the write-time strip not merely harmful but redundant:
context_manager.go:190 already builds every request through ModelMessages on
its own.

Change

ProjectionMessages — the same projection, ToolExecution preserved. The strip
stays at the provider boundary where it belongs. Both functions and their shared
implementation move to provider/projection.go: deriving the two copies of a
transcript is one responsibility, and provider.go was already carrying recorded
file-size debt that keeping them there would have widened.

Tests

The regression test uses a === RUN fixture on purpose. A synthetic
"error: ..." body survives either way through the text-prefix arm — which is
exactly what let this sit unnoticed. It asserts three things per fold: the
failure is still in the projection, its record is still readable, and no
ToolExecution reaches the provider request.

Verified by mutation, not just by passing: restoring ModelMessages at the write
site turns it red at fold 2 with the failure record was stripped, so the next fold cannot classify it. Restored and re-verified green.

Compatibility

ToolExecution is already persisted in canonical transcripts (its own doc
comment says so), so no new field enters the sidecar format and no privacy
boundary moves. A projection written by an older build simply has no record to
read, degrading to today's behaviour rather than failing.

Verification

gofmt -l .        clean
golangci-lint     0 issues
repolint          113538 — 33 lines BELOW the main-v2 baseline (113571)
go test ./...     all green, zero failures

Cache-impact: none - the provider-visible bytes are byte-identical. ProjectionMessages differs from ModelMessages only in a field that ModelMessages strips again at every request boundary, so no request payload, prompt-cache prefix, or projection fingerprint changes; providerVisibleFingerprint calls ModelMessages itself.
Cache-guard: internal/agent/failure_survives_folds_test.go asserts no ToolExecution reaches provider.ModelMessages output on every fold, alongside the unchanged internal/agent/cachehit_e2e_test.go.
Documentation-impact: updated - docs/SPEC.md "What survives a fold" now explains why a stored projection keeps the ToolExecution record that a provider request does not, with the matching section in docs/SPEC.zh-CN.md.