feat(loop-detection): defer warning injection

[ggnnggez]

Fixes #2733.

keeping this PR as draft until the 2.0-m1 patch is released.

Summary:

• Defer loop warning injection from after_model to wrap_model_call/awrap_model_call so tool-call/tool-message pairing stays intact.
• Queue loop warnings per thread and append them as HumanMessage(name="loop_warning") on the next model request.
• Remove the temporary channel-side loop-warning display filter now that warnings no longer mutate AIMessage content.
• Pending warnings are scoped by (thread_id, run_id); before_agent clears stale warnings from older runs, and after_agent clears undelivered warnings for the current run.
• Multiple pending warnings in the same run are deduplicated and merged into one hidden HumanMessage(name="loop_warning").

Tests:

• uv run pytest tests/test_loop_detection_middleware.py
• uv run pytest tests/test_channels.py tests/test_loop_detection_middleware.py

[M-Raquel]

I’m still pretty new to this part of the stack, so I appreciate how clearly the behavior is explained here. It helped clarify why injecting the warning earlier caused issues with the tool‑call pairing rules. One thing I’m curious about: could multiple queued warnings accumulate in edge cases, or does the drain logic ensure only one warning is ever surfaced per cycle? I’m trying to understand how this behaves under repeated loop conditions.

[ggnnggez]

@M-Raquel
Thanks for the insightful comment. Short answer: after the latest updates, queued warnings are now scoped by both thread and run, and multiple pending warnings are merged before injection.

Under the normal agent loop, accumulation should still be uncommon. A warning is enqueued in after_model only after a repeated tool-call pattern is detected, then drained on the next wrap_model_call, after the corresponding tool responses have already been added. That preserves the provider-required AIMessage(tool_calls) -> ToolMessage pairing.

The important edge case is when a run stops before that next model call, for example interruption or failure during tool execution. The previous version could leave a thread-scoped warning behind and drain it into a later invocation for the same thread. The latest update scopes _pending_warnings by (thread_id, run_id), clears stale warnings for older runs in before_agent, and clears undelivered warnings for the current run in after_agent, so a warning from one run should not leak into another run.

If multiple warnings are pending inside the same run, they are deduplicated and merged into a single HumanMessage(name="loop_warning") appended at the end of the outgoing request. So the behavior is protocol-safe and now semantically scoped to the run as well.