[FEATURE]: compaction should keep a Code Mode step's return value, not just its code #58717

Code Mode collapses N tool calls into one step: the transcript keeps a code block and one return value, the sandbox does the rest. I cannot predict what compaction does with that, and the answer changes how I write the programs.

Two specific unknowns:

1. When compaction decides what to keep, does a Code Mode step weigh as one message or as its tokens? A step with 40 lines of code and a 200-byte return is cheap in the transcript and may represent a lot of work. If the accounting is by message, that step survives on almost no budget while six ordinary tool calls get dropped.
2. What does keep.tokens count? If it counts tokens of the kept transcript, one large code block can eat the whole budget alone. If it counts messages, everything the program learned can disappear in a single cut.

Why this is not theoretical here: my average context is 126,169 tokens per request with auto: true and the V2 fields (keep.tokens, buffer). Sessions run long enough that compaction fires regularly. When it does, the return value of the last Code Mode step is the one thing I cannot reconstruct cheaply. Re-running a program costs the same tokens it cost the first time; a summary of what it printed does not.

What would help

• Document the accounting: does a Code Mode step count as one message, and does keep.tokens measure message tokens or parts?
• Keep the returned value verbatim, the way tool results are kept, and let the code block be summarized. Code is reproducible from a description; the output is not. If the program returned [{url, ok, mention}], that array is the finding, and the 40 lines that produced it are not.

I am not asking for the sandbox to survive compaction. I am asking that the result of the work survives it.

Related: #58708 (budget and per-tool breakdown), and #58463 for the separate ceiling problem between buffer and the output reservation.