bash tool: unbounded stdout/stderr buffering can OOM the agent

[euxaristia]

Problem

The bash tool (and to a lesser extent exec_command) allocates full command output into bytes.Buffer with no size limit:

// internal/tools/bash.go:127
var stdout bytes.Buffer
var stderr bytes.Buffer
command.Stdout = &stdout
command.Stderr = &stderr
...
output := formatBashOutput(stdout.String(), ...)

Other tools (grep, read_file, web_fetch) use applyOutputBudget + io.LimitReader. Bash does not.

Impact

• Easy OOM or unresponsiveness on large output (cat huge file, gh pr with thousands of comments, find /, verbose tests, etc.).
• Directly caused the "Not enough memory resources..." errors reported during PR review work.
• No backpressure; the process can be killed before the command even finishes.

Suggested fix

• Add a reasonable byte limit (e.g. 10-50 MiB) + io.LimitReader for stdout/stderr in bash.go (and review exec_command).
• Reuse or extend applyOutputBudget / max_output_tokens logic.
• Truncate early and surface a clear message + suggestion to narrow the command.

[Vasanthdev2004]

Fixed by #484 (the bash output budget commit). bash used to buffer stdout/stderr into unbounded bytes.Buffers; it now streams each into a bounded buffer that keeps only a capped head plus a rolling tail (96KB each, compacted at 2x so peak memory stays ~2x the budget) and drops the middle as it arrives — so cat huge.log, yes, or a verbose test run can't grow memory before truncation. The true byte counts still feed the "N bytes omitted" marker and the raw/emitted/truncated Meta fields, matching the other tools. Closing.