feat: add opt-in loop detection for repetitive tool calls

[sheeki03]

Problem

During a 45-minute security audit, the agent entered a loop of 60+ consecutive search_code calls with no progress. There was no mechanism to detect or abort this — the task ran until max_turns was exhausted, wasting API credits and time.

Depends on: #216 (auto-save scaffolding)

Changes

Loop detection engine (runner.py)

check_consecutive_tool_loop() — Module-level function that tracks consecutive same-tool-name calls. When the count reaches the threshold, raises LoopDetectedError. Extracted as a testable function with explicit state parameters; on_tool_end_hook delegates to it.

LoopDetectedError — New exception with tool_name and count attributes. Caught in the retry loop as non-retryable (immediately breaks, saves session, re-raises).

Behavior:

• Counter increments when the same tool fires consecutively
• Counter resets to 1 when a different tool fires
• Counter resets between prompts in repeat_prompt mode (prevents false positives when prompt B's first tool matches prompt A's last)
• Skipped entirely for async_task=True (concurrent tool calls make consecutive counting meaningless)
• On detection: saves triggering call to auto-save log (if enabled), then raises

Configuration

Per-task via max_consecutive_same_tool field, or globally via LOOP_MAX_CONSECUTIVE env var:

Setting	Behavior
Omitted / null	Inherits from LOOP_MAX_CONSECUTIVE env; if unset or 0, disabled
0	Explicitly disabled, even when env var is set
Positive integer	Enabled at that threshold

Invalid (non-numeric) LOOP_MAX_CONSECUTIVE values are caught and fall back to 0 with a warning, matching AUTO_SAVE_INTERVAL behavior.

Model (models.py)

Adds max_consecutive_same_tool: int | None = None to TaskDefinition. Extra fields are already allowed (model_config = ConfigDict(extra="allow")), so existing YAML files without this field parse without changes.

Documentation

• doc/GRAMMAR.md: Full section with semantics table and YAML example
• README.md: Brief mention in Taskflows section with link to GRAMMAR.md

Tests

Unit tests (TestLoopDetection, 10 tests): threshold triggering, alternating tools reset counter, disabled via 0 and negative, counter reset on tool change, state mutation visibility, TaskDefinition field acceptance/defaults

Integration tests (TestLoopDetectionIntegration, 4 tests): Drive run_main() → on_tool_end_hook → check_consecutive_tool_loop() through the real callback path by mocking deploy_task_agents:

• Task field triggers detection
• LOOP_MAX_CONSECUTIVE env var fallback
• Explicit 0 disables even with env set
• async=True bypasses detection entirely