fix(agent): budget file groups by review body size, not just diff size (#1171)

[beillahi]

Fixes #1171.

Problem

enforceGroupTokenBudget splits a group only when sum(CountTokens(d.Diff)) exceeds the limit — diff text only. But reviewing a patch reads the surrounding file body via file_read, so a grouped item's context is dominated by member bodies, not diffs. A group of small-diff / large-body files (generated config, dashboards, lockfiles, fixtures) therefore sails past the diff-only budget, is bundled into one review item, and then overflows at review time — returning StopCompression ("context compression exceeded its threshold") and failing every member at once. The same files review cleanly on their own PRs, where they land in smaller groups. (filterLargeDiffs has the same diff-only blind spot.)

See #1171 for the full write-up and the reproduction.

Fix

• groupReviewTokens now counts each member's Diff plus NewFileContent (the body the review actually reads). NewFileContent is already populated at parse time, so this adds no I/O.
• enforceGroupTokenBudget splits an over-budget group to per-file review — the existing fallback shape — and never tries to split a single-file group (a lone oversized body is handled by read-chunking + compression, not here).
• reviewGroupBudgetFraction = 0.55 reserves the rest of the per-item budget for the review's own working set (reasoning, tool-call framing, compression summaries that share the context window with the bodies being read).

Calibration

Measured with the project's own CountTokens: a 6-file group totaling ~97k body tokens overflowed a 160k per-item ceiling, while groups of ~77–80k reviewed cleanly. 0.55 (≈88k of a 160k budget) splits the former with margin and keeps the latter — so it fixes the overflow without over-splitting healthy groups.

Tests

Adds grouping_body_budget_test.go mirroring both real cases:

• the ~97k small-diff/large-body bundle → splits to per-file (and asserts the diffs alone stay under the limit, proving the body drives the split);
• the ~80k subset → kept as one group;
• a single oversized file → never split.

go build ./..., go vet ./internal/agent/, gofmt, and the full internal/agent suite pass; existing enforceGroupTokenBudget tests are unchanged and still green.

Notes

An alternative/complementary fix is to degrade a group to per-file after a StopCompression at review time; this PR takes the pre-dispatch path because it also avoids the wasted churn (and inflated request count) of reviewing a bundle that cannot fit. Happy to adjust the fraction or approach per maintainer preference.

[CLAassistant]

All committers have signed the CLA.

[github-actions]

✅ OpenCodeReview: Review complete: 0 finding(s) across 1 selected item(s).

[Qiyuanqiii]

This addresses the gap described in #1171 at the right layer. Accounting for the file bodies that may be pulled into the review context prevents small-diff/large-body groups from being dispatched as a single item only to fail later during compression.

The fallback to per-file review is consistent with the existing behavior, and the regression tests cover both the overflowing and healthy cases as well as the single-file boundary.

I don't see any blocking issues with the implementation. Looks good to me.

[wu21-web]

Can you clean these up? They seem long and pointless.

[beillahi]

Done — trimmed all three comments in grouping.go to the essentials and dropped the calibration narrative (that context lives in the PR description and #1171). Force-pushed.