Add budget and checkpoint guardrails for runaway review trajectories

[yxlyx]

A PR review trajectory on harness 0.0.213 ran for roughly 3 active hours before returning, despite ordinary file/tool operations being fast. The trace recorded approximately 1,829 model calls in the initial recipe outcome, including 713 main-agent calls overall, 16 subagent invocations, 3 workflows, and 143 judge calls. It performed repeated audit/fix/audit loops, 210 edits, and several full-suite reruns without surfacing an interim checkpoint. Only 19 transport retries occurred, so infrastructure retries were not the main cause.

Suggested guardrails:

• configurable wall-time/model-call/tool-call budgets for review tasks
• require user confirmation before a review transitions into a large multi-file implementation
• warn or stop on repeated review/fix cycles after validation passes
• cap or clearly preview workflow/fleet judge expansion
• automatically emit a progress checkpoint after a fixed time or call count
• distinguish independent workflow tasks from prompt variants so judging does not add unnecessary overhead

The relevant local trace is fa5e10c4f10541c7.jsonl; the initial failed review recipe reported latency_ms=10840375, model_calls=1829, and tool_calls=1003. This is a limitation/guardrail request rather than a claim that shell/file tools were slow.

[yxlyx]

Additional local-trace evidence confirms that the perceived slowness is primarily trajectory expansion, not slow basic tools or consistently slow provider calls.

Across the local trace set currently present (10 run files, 9 nonempty):

• 14,229 API events
• 28,336 tool events
• 185 direct subagent/workflow invocations
• 38.3 cumulative hours of API latency
• 1.89 GiB request bytes / 0.89 GiB response bytes
• 232 transport retry events

The large runs are dominated by child expansion:

run	API	tools	child API	judge API
a51a238250bfd8a4	6,307	11,607	3,801	397
de0c75d7468de434	3,219	6,486	2,051	220
4eb667a2286c84f9	2,200	4,910	1,057	50
1b87a2dced4fa2ed	1,2xx	2,6xx	495	26

By contrast, three ordinary local runs completed with 6, 10, and 22 API events and no children.

Basic tool latency is not the explanation. In 1b87..., file reads are effectively sub-millisecond, edit p95 is 12 ms, and CodeDB p95 is 160 ms. Main-model p50 is about 7.8 s. What makes the run take hours is hundreds/thousands of sequential model/tool cycles plus children that themselves run 20–60 model rounds each. One de0... turn alone used 1,881 API events and 3,871 tool events.

This strengthens the requested guardrails:

• hard or configurable per-turn main-model call budget;
• per-child model/tool/time budget, not only a count of direct child invocations;
• explicit preview/confirmation before a workflow introduces judge expansion;
• completion checkpoint before crossing issue/phase boundaries;
• a visible live counter (main rounds / child rounds / judges / elapsed) so the user can see a runaway trajectory early.