Spill oversized tool results into the committed blob store

[TheGreatAxios]

Closes CL-6965.

Results over MAX_RESULT_CHARS (grep, run_shell, search_files, web_fetch, MCP) were truncated with the tail discarded, so recovering it meant re-running the command. Measured consequence in the trace data behind CL-6961: the model re-pays for output it already generated.

What changed

The full pre-cut content is written via ContextStore.writeBlob, so it is staged into the same commit as the turn that produced it, and the notice names the resulting tool-output:///{key} URI to read back with read_file.

That last part matters beyond convenience: CL-6908 recorded the size cap telling the model "full output available" while pointing at content that had already been truncated, and the truncation plugin has carried a comment ever since forbidding a promise it could not keep. Going through the blob store makes the promise real.

Why it is committed, not cleaned up

An earlier revision of this work wrote to a tool-output-spill directory beside the blob store and told the model the file would be "removed when this session ends." Nothing removed it, and nothing staged it either — so the output was neither cleaned up nor part of the record.

Spilled tool output belongs in the immutable git turn history alongside every other input, output, and tool result. There is no cleanup policy, no size cap, and no eviction, and the notice makes no lifetime claim.

Honest fallback

With no blob store (tests, ad-hoc toolsets) the notice says the remainder is not retrievable and re-running gives the same cut, rather than naming a handle that would not resolve.

read_file is unaffected — it is short-circuited by the guard plugin before this cap and got a resumable cursor in CL-6961 instead.

Verification

bun run check green in full.

[linear-code]

CL-6965

[github-actions]

All contributors have signed the CLA.
_{Posted by the CLA Assistant Lite bot.}