fix: suppress internal status banners on customer-facing platforms (refs #28208)

[ozzaii]

Summary

Partial fix for #28208. The WhatsApp gateway (and any other customer-facing
platform) currently delivers Hermes-internal diagnostic banners straight
into end-user chat threads — for example:

🗜️ Context too large (~156,287 tokens) — compressing (1/3)...
🗜️ Compressed 120 → 7 messages, retrying...

Root cause: AIAgent._emit_status dispatches to the gateway adapter via
status_callback directly, which bypasses the transform_llm_output
plugin hook that sanitiser plugins typically attach to.

This PR adds a platform-aware filter to _emit_status:

• New customer_facing: bool = True kwarg (backwards-compatible default).
• New _CUSTOMER_FACING_PLATFORMS = {whatsapp, slack, signal, telegram, discord}.
• New _INTERNAL_STATUS_PREFIXES defensive glyph fallback — kept narrow
  (compression-banner category only).
• The four compression-recovery emit sites (1× 413 payload, 1× context-
  too-large, 2× compressed-retrying) now opt out explicitly with
  customer_facing=False.
• CLI / admin / api surfaces still receive every status — operator
  visibility unchanged.

Why "partial"

#28208 also requests silent-success for empty responses, broader provider-
diagnostic suppression, and a whatsapp.allow_silent_response config flag.
Those are deferred to follow-ups so this PR stays small enough to review
and land quickly. The compression-banner scope was chosen because:

• It is the one currently leaking into a real production customer chat
  (live incident 2026-05-22 in an AIRA-on-Hermes deployment), so the
  marginal value is highest.
• It is strictly subtractive on customer-facing platforms — zero
  behavioural impact on CLI / API surfaces, no public-API breakage.

Test plan

• tests/run_agent/test_emit_status_customer_facing_filter.py — 13
  new cases covering:
  • all five customer-facing platforms drop compression status when
    customer_facing=False
  • glyph fallback drops compression banners from un-migrated callers
  • real customer messages still reach the gateway on WhatsApp
  • explicit customer_facing=False drops even non-glyph messages
  • CLI / api_server / empty-platform surfaces always receive status
  • status_callback exceptions remain swallowed (fault-tolerance kept)
• Existing test_empty_response_emits_status_for_gateway still passes.
• Existing test_context_compression_triggered still passes.
• No new dependencies; no public-API breakage (new kwarg has a default).

Out of scope (follow-up PRs)

Tracked under #28208 — happy to take any of these in this PR if the
maintainers prefer a wider scope:

1. Silent-success path for empty model responses (config-gated).
2. whatsapp.allow_silent_response: true / suppress_diagnostics: true
   config flag wiring.
3. Broader internal-banner suppression beyond compression: empty-response
   retry (⚠️ Empty/malformed), rate-limit (⏱️/⚠️/❌), retrying (⏳),
   max-retries (⚠️/❌), non-retryable (⚠️), provider-auth (⚠️),
   proxy (⚠️). My local deployment ships these in the glyph fallback
   for defensive coverage, but each touches an additional set of emit
   sites and felt big enough to deserve its own review.

[jacobburrell]

This seems great, but it does seems to be separate from #18848 since AFAIK the gateway will nudge the model to spit out a response even if status banners aren't dumped into the platform.

Also I would like the option to see status banners elsewhere. Perhaps home channel or another interface so that admins or the owner of the hermes setup can be notified/see the logs or info lost from the status banner info.

Just not appropriate for non admins to see this.

[teknium1]

Thanks for isolating a real customer-facing failure mode. The current main architecture has moved the relevant logic, so this needs a small re-scope rather than a direct cherry-pick.

Problems

• Compression recovery now buffers status in agent/conversation_loop.py:3617 and agent/conversation_loop.py:3638; terminal failure flushes it at agent/conversation_loop.py:3646 through run_agent.py:1026-1029. The PR's old run_agent.py emit-site edits therefore no longer cover the live path.
• Delivery policy is now centralized in gateway/run.py:440-457, with only programmatic surfaces retaining raw diagnostics (gateway/run.py:94-107). A five-platform allowlist in AIAgent would duplicate and narrow that policy.

Suggested changes

• Extend the gateway noise classifier for the current Context too large … compressing and Compressed … retrying status forms, and add them to tests/gateway/test_telegram_noise_filter.py across chat and raw programmatic surfaces.

Automated hermes-sweeper review.