fix(gateway): resume follows the compression tip so post-compression replies render

[OutThisLife]

Summary

Fixes the recurring desktop report: "I send a message, it starts working, I look away, and when I come back the reply isn't there" — on large sessions, the response is generated and persisted but never shows up under the user's message.

Root cause is session rotation on auto-compression, not a render bug:

• Auto-compression ends the live session and forks a continuation child (linked via parent_session_id); the turns generated after compression — including the assistant's response — land in the continuation, not the original session.
• SessionDB.resolve_resume_session_id() only redirected an empty head to a descendant (the --resume loads empty chat after context compression; exit banner points at wrong session id #15000 case). A long-lived parent keeps its own flushed message rows, so it was never redirected — and every resume path anchored on the parent id reloaded the pre-compression transcript, missing the response.
• The desktop's chat is routed on the pre-rotation id (the id when the chat was opened), so both the gateway session.resume RPC and the REST /messages read missed the continuation.

Changes

• hermes_state.resolve_resume_session_id() now follows the compression-continuation chain forward via the existing get_compression_tip() before its empty-head walk. get_compression_tip() is lineage-aware (only follows children whose parent ended with end_reason='compression', created after the parent was ended), so delegation/branch children never hijack a resume. This fixes every resume caller at the chokepoint: REST /messages, CLI --resume, gateway /resume.
• tui_gateway session.resume was the one resume path that bypassed the resolver (it used the raw target id). It now routes through resolve_resume_session_id() (non-lazy only — lazy watch windows must stay on their exact child branch). Resolving up front also re-anchors the live-session fast path, so a still-live rotated session is reused by its new key instead of rebuilding a duplicate agent on the stale parent.

Premise verification

tests/hermes_state/test_resolve_resume_session_id.py::test_follows_compression_tip_when_parent_retains_messages fails on current main (resolve_resume_session_id("root") returns "root", the pre-compression parent) and passes with this change.

Test plan

• resolve_resume_session_id follows the tip even when the parent retains messages; not confused by a delegation child
• session.resume binds the agent to the continuation tip and returns the post-compression reply
• Existing resume callers green: tests/hermes_cli/test_web_server.py, tests/cli/test_cli_resume_command.py, tests/cli/test_resume_display.py, tests/cli/test_resume_quiet_stderr.py, tests/gateway/test_resume_command.py, tests/test_lazy_session_regressions.py, tests/test_hermes_state.py, tests/test_tui_gateway_server.py (only the unrelated, environment-dependent test_browser_manage_connect_default_local_reports_launch_hint fails locally — no Chromium on the box)

Follow-up (not in this PR, to keep it one idea)

The desktop prefers the REST /messages snapshot over the resume payload when non-empty; with the resolver fixed both now agree. A separate cleanup could make the gateway re-anchor _find_live_session_by_key to also match a session's pre-rotation id directly, but resolving the tip up front already covers the reuse path.

[github-actions]

🔎 Lint report: fix/resume-follows-compression-tip vs origin/main

ruff

Total: 0 on HEAD, 0 on base (➖ 0)

🆕 New issues: none

✅ Fixed issues: none

Unchanged: 0 pre-existing issues carried over.

ty (type checker)

Total: 11030 on HEAD, 11028 on base (🆕 +2)

🆕 New issues: none

✅ Fixed issues: none

Unchanged: 5780 pre-existing issues carried over.

Diagnostics are surfaced as warnings — this check never fails the build.