[BUG] /resume displays old compaction summary instead of latest messages in long-running sessions

Description

When using /resume on long-running sessions (100MB+, months of continuous use with many compactions), the conversation displays content from an old compaction summary instead of the latest messages. The latest messages exist in the JSONL file but are never shown.

Steps to Reproduce

1. Have a long-running session over weeks/months with many compactions (30+ compact_boundary entries)
2. Session JSONL grows to 100MB+ (e.g., 120-180MB)
3. End the session
4. Start a new session and /resume
5. The conversation shows content from an old compaction point (weeks/months back), not the latest messages

Expected Behavior

Resume should display the most recent messages from the session, rebuilding from the last compact_boundary in the JSONL.

Actual Behavior

Resume appears to pick up from an earlier compact_boundary, showing content from weeks or months ago. The latest messages exist in the JSONL (verified by parsing the file) but are never displayed.

Root Cause Analysis

The session JSONL contains multiple compact_boundary entries (30+ in a months-long session). Resume seems to reconstruct from an older boundary rather than the last one. The more compaction boundaries exist, the further back resume lands.

Workaround

Stripping all JSONL entries before the last compact_boundary forces resume to use the correct (latest) checkpoint:

# Keep only from last compact_boundary onwards
with open(session_file, 'r') as f:
    lines = f.readlines()

last_boundary = 0
for i, line in enumerate(lines):
    obj = json.loads(line.strip())
    if obj.get('subtype') == 'compact_boundary':
        last_boundary = i

kept = lines[last_boundary:]
with open(session_file, 'w') as f:
    f.writelines(kept)

This confirms the data is intact — resume just isn't reading from the right position.

Environment

• Platform: Linux (Arch Linux)
• CLI version: Tested on 2.1.86 through 2.1.92
• Session sizes: 121MB (3800+ lines, 4 compact boundaries) and 183MB (22000+ lines, 30 compact boundaries)
• Both sessions were long-running (months of use with repeated /resume cycles)

Related Issues

• #22204 — Resume hangs with large sessions (different: this is about display, not performance)
• #39316 — 400 error on resume (different: that's a crash, this silently shows wrong content)