Bug Description

When a long-running gateway session triggers automatic context compression (Session split detected), if the split occurs at the exact moment the agent returns its final response, the response is persisted to the new child session file but never sent to the messaging platform (Feishu/Discord/Telegram/WhatsApp/etc).

This creates a confusing UX where:

• The session transcript (JSON) shows a complete assistant response
• The user on the platform receives nothing
• The agent appears to have "done the work but gone silent"

Steps to Reproduce

1. Start Hermes gateway with a platform adapter (observed on Feishu, likely affects all platforms)
2. Have a conversation long enough to approach the compression threshold
3. Send a message that requires significant processing (many tool calls / long generation time)
4. If the session happens to cross the compression threshold during that turn, the bug triggers

Evidence Pattern

From agent.log in an affected session, the following log pattern is observed:

... Session split detected: <parent_session_id> → <child_session_id> (compression)
... response ready: platform=feishu chat=<chat_id> time=<duration>s api_calls=<n> response=<n> chars

# ❌ MISSING: "Sending response" log line
# Next log entry proceeds to unrelated routine work, no platform delivery occurred

The response is saved in the child session JSON file (as an assistant message), but the platform adapter never sends it.

For comparison, a normal successful flow always shows:

... response ready: ... response=<n> chars
... gateway.platforms.base: [Feishu] Sending response (<n> chars) to ...

Root Cause Analysis

When Session split detected fires, the gateway creates a new child session lineage. If the agent's run_conversation() returns its final response after the split event has swapped the active session reference but before the platform adapter's send call executes, the send logic appears to target the wrong (or already-closed) session context, causing the delivery to be silently dropped.

This is likely a race condition in the session handoff path during compression.

Expected Behavior

Every response ready event must have a corresponding platform delivery attempt. Session split/compression should not drop in-flight responses.

Actual Behavior

Responses generated at the compression boundary are persisted but not delivered.

Related Issues

• [Bug]: sessions still leak open rows and ghost stubs across gateway/cli/cron after completion or exception paths #12029 — "sessions still leak open rows and ghost stubs across gateway/cli/cron" (proposed fix: "Make session split/compression explicitly finalize or transition the prior session")
• [Bug]: Compression trigger includes reasoning tokens, causing premature session splits for thinking models (GLM-5.1, QwQ, etc.) #12026 — Compression trigger includes reasoning tokens, causing premature session splits

Environment

• OS: macOS (darwin)
• Python: 3.11.15
• Hermes Version: latest (2026.4.x)
• Platform: Feishu (Lark)
• Profile: independent profile with custom gateway

Proposed Fix

Ensure the platform adapter holds a reference to the target chat/channel ID independently of the active session object, so that even if a session split occurs mid-response, the delivery still targets the correct platform destination.

Alternatively, delay the session split until after the current turn's response has been fully dispatched.