Large tool output (e.g. run_shell_command) sent to model uncapped exceeds 1M input limit and permanently wedges the session

### What happened

In a long-running headless session (driven over ACP), the agent ran a single `run_shell_command` whose output was a ~24 MB single-line JSON blob (a `package-lock.json` / npm-metadata dump). The very next model turn failed with:

```
HTTP 500: Failed to generate content: The input token count exceeds the maximum number of tokens allowed 1048576.
```

~24 MB of text is roughly 6M tokens, about 6x the model's 2^20 input limit, contributed by a **single** tool result.

The worse problem is that the session never recovers: the oversized `functionResponse` stays in the conversation history, so **every subsequent turn fails with the identical 500**, and an automated retry just re-runs the same command and re-poisons the context. The session is permanently wedged.

### Evidence

`gemini-cli` does persist the full tool output to a file:

```
~/.gemini/tmp//tool-outputs/run_shell_command_1.txt # 24,039,557 bytes, 1 line
```

but it also appears to include that full output in the model request (hence the 1M overflow). I could not find any setting that caps the portion of tool output sent to the model — grepping the installed bundle (`@google/gemini-cli/bundle/gemini.js`) for `truncateToolOutput*`, `enableToolOutputTruncation`, `maxOutput*`, "Output too large", "truncated" returned nothing in this version.

### Expected behavior

When a tool returns output far larger than the model's input window, gemini-cli should bound what reaches the model — e.g. send a head/tail slice plus a "full output saved to " note (it already writes the full output to disk), and/or detect that the assembled request exceeds the model's input limit and drop/summarize the largest historical tool results instead of returning the same error on every future turn. Today one oversized command permanently kills the session.

### Question

Is there a configuration knob in 0.42.0 to cap tool-output size sent to the model? If not, would a default cap (with full output preserved on disk) be in scope?

### Environment

- `gemini --version`: **0.42.0**
- Auth: `oauth-personal`
- Mode: headless, driven via ACP (non-interactive)
- Model: default Gemini (1,048,576-token input window)
- OS: Linux container (node image)