fix(agent): warn instead of silently spiraling on repeated identical tool calls

[albatrossflyon-coder]

Problem

The tool-call loop has no repeat/loop detection at all. A stuck agent can burn its entire max_iterations budget calling the exact same tool with the exact same arguments over and over, with no signal to the user or the model that it's happening -- it just looks frozen from the outside until the iteration cap finally kicks in.

Ran into this directly: an agent spiraled for several minutes checking the same env var through half a dozen different mechanisms (exec, grep, reading its own session log, etc.) before eventually landing on the right answer -- no single one of those calls repeated identically enough times in a row to be an obvious "stuck" signal by iteration count alone, but a simpler variant of the same problem (identical tool + identical args, repeated) is easy to construct and easy to detect.

Fix

Adds a lightweight, order-independent per-turn signature tracker (tool name + arguments) to AgentRunner.run(). After 3 identical tool-call rounds in a row, it injects one system-role warning into the conversation telling the model to stop and try something else, then resets the tracker -- it informs, it does not block, so legitimate repeated reads/checks still execute normally.

Scope

This catches repeats across separate iterations (the failure pattern above). It intentionally does not catch several identical calls bundled into a single turn (e.g. 3 parallel read_file calls in one response) -- confirmed live during testing that this is genuinely a different pattern. Happy to extend coverage there too if maintainers think it's worth it, but wanted to keep this PR scoped to the pattern actually observed.

Testing

• Two new tests in tests/agent/test_runner_safety.py: warn-once-after-three-identical-calls, and no-false-positive-on-two-repeats-or-varied-arguments.
• Full suite: 4885 passed, 0 failed, 33 skipped (pre-existing skips, unrelated).
• ruff check clean on both changed files.
• Manually verified against a live gateway (patched the installed copy, restarted, dispatched real test tasks) -- confirmed the change imports and runs cleanly against a real running instance, not just the test suite.

Non-goals

Not attempting a more general loop-detection framework here (state hashing across N steps, progress detection, etc.) -- keeping this to the smallest change that addresses the concrete failure pattern, per the contributing guide's "prefer the smallest change that solves the real problem."

[albatrossflyon-coder]

Pushed an extension closing the gap disclosed in the PR description — 9e21f86.

_detect_tool_call_loop tracks one signature per whole round, so it only catches a loop that repeats identically across separate rounds. It couldn't see N identical calls batched into a single round (e.g. three parallel read_file calls with the same path) — that round produces its own distinct joined signature exactly once, so it never looked like a repeat.

Added _detect_intra_round_duplicate_calls(), checked alongside the existing cross-round guard. Fires the first time a round contains 3+ identical calls, rather than requiring the round to repeat.

Two new tests: warn-on-three-batched-identical-calls, no-false-positive-on-two-or-varied. Full suite: 5915 passed, 2 pre-existing failures unrelated to this change (filed separately as #5348), 44 skipped. ruff check and basedpyright --strict clean on both changed files. vuln-hunter scan_diff clean.