Add turn-level loop escalation policy for repeated identical tool-call patterns

[andrew-ellis-engineering]

Summary

After adding a duplicate-call guard for repeated identical local tool calls, Nanobot should also have an explicit loop interruption/escalation policy when repetitive tool-call patterns are detected.

This is a separate product behavior issue from the immediate safety guard.

Problem

Even with per-call blocking, turns can still degrade into low-progress loops unless there is turn-level handling (for example escalation, forced strategy shift, or early stop criteria).

Proposed Direction

Add a configurable turn-level policy that reacts to repeated identical tool-call patterns (local and/or external), for example:

• trigger advisory escalation once a repeated-pattern threshold is hit
• force a different action class (summarize prior results, ask clarifying question, or choose a different tool)
• optionally terminate turn early with a clear reason when no progress is being made

Scope Questions

• Should this policy live in core runner logic or advisor/router orchestration?
• Should thresholds be global or per-tool/per-category?
• Should behavior differ by interaction mode (interactive vs batch)?
• What telemetry/logging is needed to tune false positives?

Acceptance Criteria (Initial)

• Repeated-pattern detection can trigger a deterministic escalation/interrupt path
• Behavior is configurable and observable in logs
• Regression tests cover both trigger and non-trigger paths
• Works with existing external lookup repetition safeguards

Notes

Keep this separate from the first PR that introduces the local duplicate-call guard.

[chengyongru]

Closing — same reasoning as #3699. max_iterations and repeated_external_lookup_error already cover this space. No user reports demonstrate this as an actual problem. Happy to revisit if concrete evidence comes up.