fix(agent): suppress intermediate retry status messages in chat thread

[shagghiesuperstar]

Problem

When a streaming request to the LLM provider fails mid-stream (e.g. ReadTimeout, ConnectionError, RemoteProtocolError), Hermes retries with a fresh connection. Each retry emits a status message that accumulates permanently in the chat thread:

⚠️ Connection to provider dropped (RemoteProtocolError). Reconnecting… (attempt 2/3)
⚠️ Connection to provider dropped (RemoteProtocolError). Reconnecting… (attempt 3/3)
<the actual successful response>

On self-hosted providers with frequent transient errors (backend restarts, rate limits, OOM recovery), these warnings accumulate and don't reflect the final outcome.

Root Cause

Source: run_agent.py — the retry loop calls _emit_status() for intermediate retry messages. _emit_status() sends directly to the platform adapter, which posts a new message (not an update to an existing message).

Fix

Replace _emit_status() with logger.info() for intermediate retry messages. Only the final outcome (success via "Reconnected — resuming…" or failure via "Connection to provider failed after N attempts") is emitted to the user. Intermediate attempts go to logger.info and stay in logs.

Changes

• run_agent.py: Replace _emit_status() with logger.info() for both the standard retry path (line ~6591) and the mid-tool-call retry path (line ~6525).
• Added reference to issue UX: streaming retry status messages accumulate in chat thread even after successful retry #5151 in both code comments.

References

• Issue UX: streaming retry status messages accumulate in chat thread even after successful retry #5151: UX: streaming retry status messages accumulate in chat thread even after successful retry #5151
• Issue [Bug]:Hermes reconnects after 180s of provider silence even though oMLX is still processing #5889: [Bug]:Hermes reconnects after 180s of provider silence even though oMLX is still processing #5889 (related — stale stream timeout fix)
• PR fix(agent): disable stale stream timeout for local providers #6368: fix(agent): disable stale stream timeout for local providers #6368 (stale stream timeout fix for local providers)

Impact

• Before: 6+ warning messages accumulate in a session with 3 transient retries
• After: Only the final "Reconnected — resuming…" or "Connection to provider failed" is visible
• Users can still see intermediate retries by checking agent.log
• Zero behavioral change — retries still work identically, only the message delivery changes

[teknium1]

This looks implemented on current main by the later retry-status buffering work. Automated hermes-sweeper review.

Evidence:

• PR feat(agent): buffer retry/fallback status, surface only on terminal failure #33816 merged as 67011cc0d76b7047320b2760e948b4e4488c24ca and explicitly buffers retry/fallback status messages, surfacing them only on terminal failure.
• run_agent.py:828 defines the retry status buffer helpers; the comments state retry/fallback messages are dropped on successful recovery and flushed only when all retry/fallback paths exhaust.
• agent/stream_diag.py:261 now sends stream-drop reconnect notices through agent._buffer_status(...), not direct _emit_status(...).
• agent/chat_completion_helpers.py:2288 and agent/chat_completion_helpers.py:2338 route both mid-tool-call and normal stream retry call sites through _emit_stream_drop(...).
• agent/conversation_loop.py:4079 clears the retry status buffer once successful assistant content is reached, so intermediate retry chatter is not left in the chat thread after recovery.
• Covered by tests/run_agent/test_retry_status_buffer.py.

Fixed in v2026.5.28 and later.