[Feature]: Suppress or throttle transient channel connection status system events

Summary

Problem

When a channel (e.g. WhatsApp) briefly disconnects and reconnects, the gateway injects system messages into the active session:

Problem to solve

These are useful for debugging, but during normal operation they're noise. A 6-second reconnect isn't something the user or agent needs to know about, especially when the user is interacting via a different surface (e.g. webchat).

Messages sent during the disconnect window are silently lost, which is the actual problem. The status notifications don't help the user recover from that.

Proposed solution

Proposal

One or more of:

1. Threshold-based suppression: Only surface disconnection events if the channel has been down for longer than a configurable duration (e.g. channels.<channel>.healthMonitor.notifyAfterMs: 30000). Short reconnects stay silent.

2. Per-channel system event verbosity: A config flag like channels.<channel>.statusEvents: "silent" | "errors" | "all" (default "all" for backwards compatibility).

3. Surface-aware filtering: Don't inject WhatsApp connection status into non-WhatsApp sessions. If the user is on webchat, WhatsApp reconnecting isn't relevant unless it stays down.

Alternatives considered

Current workaround

None. The events are injected unconditionally. Disabling the channel entirely works but defeats the purpose.

Impact

Impact

• Affected: Any user with WhatsApp (or other reconnecting channels) enabled alongside other surfaces (webchat, Telegram, etc.)
• Severity: Annoying. Doesn't block workflow but adds noise to every active session and can trigger unnecessary agent processing of status events.
• Frequency: Intermittent but regular. WhatsApp connections cycle multiple times per day during normal operation. Each cycle generates two system messages.
• Consequence: Session clutter, wasted agent context window, and minor token cost from the agent processing irrelevant system events. The real issue (silently dropped messages during the gap) is not addressed by the notifications anyway.

Evidence/examples

No response

Additional information

No response