test(agent): lock in aggregate gating of a parallel tool batch (#192)

[justrach]

TL;DR

No code change is needed — #192's overflow window is already closed on main by the #193 pre-send gate. This PR adds the regression test the issue asked for (its ask #4) and documents why the gate covers the parallel-batch case.

Why it's already handled

Agent.runTurn()'s loop is:

gate (#193 inputOverCompactThreshold)  ← top of loop
  → request()
  → stepResponses()   ← appends the whole parallel tool batch to self.messages
  → loop back → gate  ← re-estimates over the appended batch
  → continuation request()

The #193 gate sits exactly between the tool batch being appended and the continuation request, and inputOverCompactThreshold → fullInputEstimateTokens serializes the full self.messages (including the freshly appended outputs). So a parallel batch that crosses compactAt() only in aggregate triggers compaction before the continuation is sent — which is #192's scenario.

(The #203 prefill baseline, in the in-flight .202 follow-ups, only makes the gate fire earlier / more conservatively; it isn't required to close this window.)

Test (the issue's ask #4)

inputOverCompactThreshold (#192): a parallel tool batch is gated as an aggregate:

• one function_call_output (~6 KB, individually far under the window and the 16 KB per-output cap) → gate does not fire;
• a six-output batch (the reported six parallel read_file calls) → aggregate serialized input crosses compactAt() → gate fires.

Verified on main: zig build test green, zig fmt clean.

Closes #192