fix(gateway): forward-resolve compressed session to tip on resident non-Telegram platforms

[RoySRose]

Summary

Fixes the resident-gateway (Discord/Slack) slice of the compaction session-fork bug (#44004): on a self-hosted Discord/Slack gateway, a long conversation keeps rotating its session_id on every auto-compression, forking orphan child sessions and reloading the oversized pre-compression parent on each turn — an endless preflight-compression loop where one session was observed climbing past the model's context cap and spawning multiple orphan lineages in minutes.

Why existing fixes don't cover this path

The same #44004 root cause has three distinct intake paths, each needing its own forward-resolution to the compression tip:

• fix(gateway): resume follows the compression tip so post-compression replies render #48633 (merged) — SessionDB.resolve_resume_session_id() + TUI/desktop resume (tui_gateway/server.py).
• fix(api_server): resolve compressed sessions to their live tip for stateless clients #44103 (open) — gateway/platforms/api_server.py, stateless OpenAI-compatible clients.
• this PR — the resident gateway message path GatewayRunner._handle_message() → session_store.get_or_create_session() in gateway/run.py.

The resident gateway path never calls resolve_resume_session_id() (only slash-commands / TUI / api_server do), and get_or_create_session() returns the stored session_key → session_id mapping verbatim without following the compression chain. The only forward-resolution in gateway/run.py lived inside the Telegram-topic-lane branch, so Discord/Slack resident lanes reloaded the pre-compression parent after every rotation.

Change

Right after get_or_create_session(), apply the same lineage-aware get_compression_tip() walk the Telegram lane already uses — for all non-Telegram resident platforms — and switch_session() the session_key forward to the tip. Telegram keeps its own binding-based healing. get_compression_tip() only follows end_reason='compression' chains and returns the input unchanged otherwise, so it's a no-op for fresh/branch/delegate sessions.

Verification

• tests/test_hermes_state.py -k compression_tip (4 passed) — the primitive.
• tests/gateway/test_telegram_topic_mode.py (44 passed) — the mirrored healing pattern, no regression.
• Live: on a Discord gateway exhibiting the fork loop, after this patch a compaction split now continues on the child tip (subsequent turns route to the child), the parent ends and stops re-growing, orphan-session count stays flat across repeated compactions, and no session exceeds the context cap.

Refs #44004, complements #48633 and #44103.

[teknium1]

Thanks for identifying the resident-gateway compression-routing failure mode. This is now implemented on current main through a centralized SessionStore repair rather than a second gateway-runner branch.

• gateway/session.py:1840-1853 resolves every existing, non-force_new routing entry to its compression tip before the normal session decision path.
• gateway/session.py:1897-1901 writes that canonical id back into the stored entry before returning it, covering resident non-Telegram platforms as well as the existing Telegram-specific binding repair.
• tests/gateway/test_restart_resume_pending.py:387-406 covers a Weixin platform source and asserts that get_or_create_session() advances a compressed parent mapping to its child.
• The implementation landed in 52d0d671e79ec1d5727881a6e8519332d04c1a07 and is included in v2026.7.7.

This is an automated hermes-sweeper review.