Last-resort tool-response truncation is O(candidates x rows) on the journal-backed send path #3857

Problem

On the journal-fed source send route from #854 (PR #3852), the last stage of the context enforcement ladder is truncateSourceToolResponses → truncateOversizedToolResponsesUnified (toolResultTruncator.ts). After every single tool-response replacement it re-projects the whole candidate from disk and writes the journal. With n rows and about n/3 tool-response candidates, a send that reaches this stage does O(n²) work.

It was measured in a test fixture during #854 CI work (tmp bench, not committed). With a 1M-token limit and mostly uncompressible 2 KiB text rows, the send stalled:

• 1,024 rows took 520 ms.
• 2,048 rows were still running at 180 s.
• 8,192 rows never reached provider preparation.

Under the limit, the same send path is linear: about 1.3 s at 8,192 rows.

This stage only runs after compression and the fallback stages have failed to bring the request under the limit, so most sessions never reach it. When a session does reach it, the turn appears to hang instead of failing fast with a context-overflow error.

Proposal

• Decide all replacements in one pass, then publish a single atomic change. Use a disk-backed running estimate per row, so the loop does not re-project after each replacement.
• Alternatively, cap the stage's work. When truncating tool responses cannot reach the limit, because the remaining rows are not tool responses, fail fast with ContextOverflowError before doing the per-candidate loop.

Acceptance

• A counting-seam test shows that projections and journal writes per send in this stage do not grow quadratically with the row count.
• An over-limit fixture at 8,192 rows either finishes or fails with ContextOverflowError within seconds.
• Request bytes are unchanged for cases where truncation succeeds.

Follow-up from #854 / PR #3852.