Bug Description

/resume can resolve a named session to a stale compression parent instead of the newest continuation child. That reopens the old row even when the logical conversation has already moved forward through one or more compression continuations.

Why this matters

Compression is supposed to preserve one logical conversation across multiple session rows. If /resume lands on the old root instead of the newest continuation, users end up resuming the wrong point in time.

Expected Behavior

When a named or explicitly selected session has continuation children created by compression, /resume should follow that chain and resume the newest continuation row by default.

Actual Behavior

Resolution can stop at the stale parent row, so the resumed session is behind the real conversation tip.

Suggested Direction

• add a helper that follows only compression continuations, not arbitrary branch/delegate children
• use that helper when resolving /resume targets by id or title
• when listing named sessions, project compressed roots to their latest continuation before presenting them
• cover gateway and state-db behavior with targeted tests

Notes

I have a tested local implementation of this behavior, but it is currently entangled with other local /resume work and needs a clean upstream port.