fix(api): serve full compression lineage in session messages endpoints (#79565)

[thatssoheil]

Fix: serve full compression lineage in session messages endpoints (#79565)

What

The desktop session-switch view showed only the latest compression
segment of a long conversation — earlier segments appeared lost. Two
endpoints shared the same child-only fetch bug:

1. gateway/platforms/api_server.py _handle_session_messages —
   resolved to the latest compression child and loaded only that child's
   rows via get_messages.
2. hermes_cli/web_routers/sessions.py get_session_messages (the
   dashboard endpoint) — same child-only resolution.

Fix

Both endpoints now serve the full compression lineage:

• api_server.py: resolve forward to the compression tip, then reuse the
  existing, tested get_resume_conversations(tip) display_history — which
  already walks the whole lineage root→tip and reconciles replayed-user
  messages (the exact overlap handling the issue asks for).
• sessions.py: use get_messages_as_conversation(include_ancestors=True)
  and page over the full lineage (limit/offset contract preserved).

No new lineage architecture — the projection already existed; this is a
surgical endpoint change. _message_response shape compatibility preserved.

Tests

• tests/gateway/test_session_messages_lineage.py (new): gateway endpoint
  returns the full root→tip lineage; uncompressed sessions unchanged.
• tests/hermes_cli/test_web_server.py (extended): dashboard endpoint
  returns full lineage, paginates across segments, guard tests for
  negative/oversized limits.

All fail on the old child-only code for the right reason ('early question' in ['latest question', 'latest answer']), pass with the fix. 155 tests
green across the three neighboring suites.

Prior art

This was previously attempted (#71857) with custom lineage projection and
caused duplicates; reusing get_resume_conversations display_history
avoids re-introducing that class of bug.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[alt-glitch]

This was generated by AI during triage.

Related: #59661 addresses the same session-message endpoints with ancestor-inclusive reads. This PR uses the existing display-history projection to preserve replay-overlap handling, so these are competing approaches rather than duplicates.

[thatssoheil]

Thanks for the pointer. I checked #59661 — it's the same bug class (#51058: compression rotation hides the parent transcript) across the same three surfaces (api_server messages, web_routers/sessions.py REST, hermes_state lineage read). Noted, and I see it's being actively shepherded (rebased on current main, sweeper keep_open).

The approaches differ in one material way worth flagging for the maintainers:

• fix(rest): include compression-ancestor messages in /api/sessions/{id}/messages (#51058) #59661 adds include_ancestors to get_messages() at the SQL level — raw rows from the whole lineage, no replay-overlap handling.
• This PR reads the lineage through get_messages_as_conversation(include_ancestors=True) / get_resume_conversations, which applies the existing replayed-user dedup + _rows_to_conversation shape normalization (same projection session.resume uses). For the desktop prefetch this matters: a compression rotation replays the parent's tail user turn into the child, and the raw SQL path can show it twice while the resume path dedups it — the prefetch and the resume would disagree.

So they're genuinely competing approaches, not duplicates. Happy to close this PR if maintainers prefer #59661's simpler SQL-level read; if the dedup-consistency argument wins, this one is the safer merge. Either way, no hard feelings — flagging for the triage decision.

[thatssoheil]

Following @friendfish's triage below (thank you - the live trace and the #59661 status check are exactly the state-of-record this thread needed): #59661 (opened 2026-07-06, a month before this issue) already implements the same fix class on the same endpoints, it is green and mergeable, and the remaining findings on it (@ehz0ah's API-fork walk + the rotation-clone residue) are tracked in that thread. I am closing this PR in its favor instead of keeping a parallel implementation open - see my post on #59661 for the two findings my branch carried that are worth folding in there (cross-segment rotation-clone dedupe for non-user roles, and branch gating on the REST path).

Closing as duplicate; will delete the branch after this lands on the record. If #59661's shape changes in review, this thread's 5-segment lineage repro (326 raw rows -> 67 shown) remains the reference test case.

[thatssoheil]

Duplicate of #59661 (predates the issue; see close-comment above for the two findings worth folding in).