What Problem This Solves

#78865 asks for a platform-level circuit breaker: "If the same tool is called with similar arguments N times… block the next call", because "AGENTS.md is a suggestion… the enforcement has to happen at the platform level, not the prompt level."

Today the generic detector's critical tier requires identical results (noProgressStreak resets whenever the result hash changes). A model stuck re-issuing the same call whose output differs every time — timestamps, fresh page dumps, rate-limited errors with new request ids — only ever produces a log-side warning the model never sees, and runs until the token budget burns out.

Production incident that motivated this (OpenClaw 2026.7.1, mimo-v2.5): a model re-issued the identical exec date +%S call 62 times in an unbroken run — every result differed (seconds changed), so nothing escalated past the log warning; the turn ended only by output-token exhaustion (stopReason=length, ~34K output tokens). A second incident the same week ran a browser-workflow marathon of 141 rounds for the same reason.

Why This Change Was Made

Adds a consecutive_repeat detector: an unbroken run of byte-identical (tool, args) calls — nothing else interleaved — escalates to a critical veto at criticalThreshold, regardless of result hashes. The veto reason reaches the model as the tool result, which both breaks the streak and tells the model how to proceed.

Scope guards:

• Known polling tools are exempt (polling legitimately repeats; the existing "does not block known polling when output progresses" test passes unchanged).
• Messaging sends are exempt (they have their own volatility-strip escalation that understands which result-side changes count as progress, Bug: loopDetection cannot block message tool loops — volatile messageId in result defeats all critical-level detection paths #89090; its tests pass unchanged).
• Mixed workflows are untouched: any interleaved different call resets the streak, so productive same-args repetition inside varied work (navigate → sleep → print per item) never trips it.

Deliberate behavior change: two exec tests that pinned changing-output runs at warning level now expect the consecutive critical instead. Their original concern — the global no-progress breaker must not fire on changing results — still holds and is still asserted (via the detector kind). If you'd prefer a separate, higher threshold for this tier instead of reusing criticalThreshold, happy to adjust.

User Impact

Runaway identical-call loops stop after criticalThreshold consecutive calls with an actionable, model-visible message, instead of silently burning the run budget. No config surface changes (the detector rides the existing internal defaults; disabled together with tools.loopDetection.enabled=false).

Evidence

• pnpm test -- src/agents/tool-loop-detection.test.ts — 56/56 pass (3 new tests: unbroken-run block with varying results; interrupted run does not escalate; below-threshold stays at warning).
• pnpm run tsgo:prod — clean.
• Same design validated in production on our deployment (implemented as a plugin hook while this PR is open): a 15×-identical-exec request executed 11 calls, refused the rest with the guard message, and the model recovered and summarized cleanly — the veto text is sufficient for models to break out.
• Cross-model replays of the incident contexts (mimo, deepseek-v4-flash, kimi-k2.6/k3, minimax-m2.5, gpt-5.6, gemini-3.5-flash) show mid-tier models continue such loops 2/2–3/3 once loop history is in context — platform-level enforcement is the only reliable layer, exactly as Tool call circuit breaker needed — LLMs will blindly retry forever without one #78865 argues.

Closes #78865