feat(gateway): notify user when context is auto-compressed

[Grey0202]

Summary

When the agent's context_compressor cuts a long conversation and continues under a fresh session_id, the user has no signal that this happened — the next reply they receive is in a session whose history has been summarised, which can be confusing if they reference earlier turns.

This adds an opt-in notification: when GatewayRunner observes that an agent result returned a different session_id than the entry it was launched with (the existing trigger for switching the gateway's session pointer), it sends one small message to the originating chat informing the user that the context has been compressed.

Behavior

• Opt-in: gated by config.compression.notify (default false).
• Customisable: config.compression.notify_message overrides the default text. The default included is intentionally short so it works on bandwidth-constrained channels (SMS, telegram).
• Non-fatal: send is wrapped in try/except; a failed notification logs at debug level and does not affect the agent reply that follows.

Example config

compression:
  enabled: true
  threshold: 0.5
  notify: true
  notify_message: "⚡ Context auto-compressed; conversation continues."

Test plan

• python -m py_compile gateway/run.py passes
• With notify: true, exercising compression on a real chat sends one notification message before the next agent reply
• With notify: false (default), behavior is identical to today
• When the platform adapter for the source platform is missing/unhealthy, the notify failure is swallowed and the reply still goes through

Notes

The compression event is detected the same way the surrounding code already detects it (the agent_result["session_id"] != session_entry.session_id comparison just above). No new state is introduced.

[teknium1]

Thanks for addressing the confusing silent-compaction experience. The underlying user-visible gap still exists on current main, but this implementation no longer reaches the default compaction path.

Problems

• compression.in_place now defaults to True (hermes_cli/config.py:1463), and in-place compaction keeps the session ID (agent/conversation_compression.py:500-505). The added session-ID-difference guard therefore does not fire for default compactions.
• Main already emits COMPACTION_STATUS before compression (agent/conversation_compression.py:516), but the gateway suppresses that exact message in _TELEGRAM_NOISY_STATUS_RE (gateway/run.py:82) before adapter delivery (gateway/run.py:453-454).

Suggested changes

• Repair the status-filter path rather than send a separate post-rotation message. This preserves the active-run, thread-metadata, and adapter status-update behavior in gateway/run.py:17812-17833.
• Update tests/gateway/test_telegram_noise_filter.py; it currently asserts the compaction status is noisy (:33, :46). The cross-referenced #40378 contains the same focused filter/test direction.

Automated hermes-sweeper review.

[teknium1]

This notification is gated on session-ID rotation, but current main defaults compression.in_place to true (hermes_cli/config.py:1463), which compacts without changing the ID. The default path therefore never reaches this block; allow the existing compaction lifecycle status through the gateway status filter instead.

[teknium1]

The opt-in compression notice this PR pioneered has landed via PR #70457 (compression.progress_notices, default off — design gate settled in issue #52995). Thanks @Grey0202 for the early identification of the need.

This branch's mechanism couldn't be salvaged directly: it fires on session_id change, which the in-place compaction default (2107b86) no longer produces, and the notification text needs to flow through the status-template system (#69550) rather than a hardcoded string. The landed gate covers the use case. Closing with credit.