fix: clear fallback streaming warnings

[cyberdyne187]

Summary:

• Emit fallback/rate-limit lifecycle notices as warning events with type=fallback so the composer status auto-clears correctly.
• Preserve existing auto-compression lifecycle SSE behavior.
• Add regression coverage and an Unreleased changelog note.

Test Plan:

• pytest tests/test_auto_compression_card.py tests/test_streaming_max_tokens_quota.py tests/test_inflight_stream_reuse.py -q
• git diff --check

[nesquena-hermes]

Summary

Reading api/streaming.py:2978-3020 on this branch and the agent-side emitters in agent/conversation_loop.py, the change tightens a real-but-narrow gap: rate-limit and fallback lifecycle messages were being dropped silently before reaching the SSE stream, so users never learned that their stream switched providers mid-turn. The new warning bridge surfaces them through the existing warning channel that static/messages.js:1903-1913 already handles. The shape is right; the match list has some sharp edges worth tightening before this lands.

Code reference

The new branch on this PR:

_is_fallback_notice = (
    _kind == 'lifecycle'
    and (
        'rate limited' in _lower
        or 'switching to fallback' in _lower
        or 'falling back' in _lower
        or 'fallback activated' in _lower
        or 'pool may recover' in _lower
        or 'waiting for pool' in _lower
    )
)
if _is_fallback_notice:
    put('warning', {'type': 'fallback', 'message': _message})

The frontend already drains this event at static/messages.js:1903-1913:

source.addEventListener('warning',e=>{
  if(!S.session||S.session.session_id!==activeSid) return;
  try{
    const d=JSON.parse(e.data);
    setComposerStatus(`${d.message||'Warning'}`);
    if(d.type==='fallback') setTimeout(()=>setComposerStatus(''),4000);
  }catch(_){}
});

So type: 'fallback' is correctly wired to the auto-clearing 4-second composer status already in place.

Diagnosis / Recommendation

A few things worth checking before merge:

1. The match list doesn't line up with what the agent actually emits. Grepping ~/.hermes/hermes-agent for the strings in the match list, the actual emit sites at agent/conversation_loop.py:1128, 1198, 1260, 2260, 2621, 2692 use phrases like "Empty/malformed response — switching to fallback...", "Max retries (...) for invalid responses — trying fallback...", "Rate limited — switching to fallback provider...", and "Non-retryable error (HTTP ...) — trying fallback...". The new match list catches 'switching to fallback' and 'rate limited' (good), but 'trying fallback' is the more common emit phrase and isn't covered — so a 5xx-retryable fallback or invalid-response fallback would still be silently dropped. Either add 'trying fallback' to the list or simplify to a single 'fallback' in _lower (with a 'rate limited' in _lower companion for the rate-limit case before any fallback fires).
2. 'pool may recover' / 'waiting for pool' aren't currently in the agent. grep -rn "pool may recover" ~/.hermes/hermes-agent returns no hits. These look speculative. Either drop them or point at the future emit site so reviewers know why they're listed.
3. Non-fatal warnings can stack. setComposerStatus(...) in the existing handler overwrites the previous string. A turn that rate-limits, falls back, then rate-limits again on the fallback will flash three statuses in quick succession, and the 4-second timer is shared (each timer races against the others, so the last one wins). Probably fine in practice, but if a user is reading along it can be jarring. Not a blocker.

Test plan

The regression in tests/test_auto_compression_card.py confirms the existing compressing path still works. For the new warning emission, an integration-shaped test that drives _agent_status_callback("lifecycle", "Rate limited — switching to fallback provider...") and asserts a warning event was emitted with type: 'fallback' would close the loop. That goes in tests/test_streaming_* to match neighborhood.

Manual: configure a provider you know to rate-limit, watch the composer status when fallback kicks in. Before this PR, nothing visible; after, a brief "Rate limited — switching to fallback..." status that clears after 4s.

The CHANGELOG entry covers the user-visible behavior change. Worth landing once the match list is tightened to cover 'trying fallback' and the speculative phrases are dropped.

[cyberdyne187]

Thanks — addressed the review feedback.

Updated the lifecycle fallback matcher to include trying fallback, which covers the invalid-response / non-retryable fallback paths emitted by agent/conversation_loop.py.

Also removed the speculative pool may recover / waiting for pool strings since there are no current emit sites for those phrases, and added predicate coverage for the actual rate-limit and trying fallback lifecycle messages.

Verification run locally:

• python -m pytest tests/test_auto_compression_card.py tests/test_streaming_max_tokens_quota.py tests/test_streaming_session_sidebar.py -q → 38 passed
• python -m py_compile api/streaming.py tests/test_auto_compression_card.py
• git diff --check

Branch is rebased on current origin/master and pushed.