### Evidence

Checkpoint files are present and non-empty on the filesystem:


# Session 55ba12f0 — 10 checkpoints (890KB to 4.1MB each)
55ba12f0-...-cd7b95340384.checkpoint.14f758d4-....jsonl  (1.5MB)
55ba12f0-...-cd7b95340384.checkpoint.30fd2227-....jsonl  (3.8MB)
55ba12f0-...-cd7b95340384.checkpoint.330fbb19-....jsonl  (1.1MB)
... (10 total)

# Session c2a92ba0 — 5 checkpoints
c2a92ba0-...-b9ebb8b793c1.checkpoint.117e0a03-....jsonl  (1.7MB)
c2a92ba0-...-b9ebb8b793c1.checkpoint.25a5f32d-....jsonl  (1.2MB)
... (5 total)

# Session 1480186e — 4 checkpoints
1480186e-...-8b1b4e843d19.checkpoint.b0ace945-....jsonl  (2.0MB)
... (4 total)


All files follow the naming convention `{sessionId}.checkpoint.{checkpointId}.jsonl` and contain valid data.
----

After a gateway restart today (due to config changes), the currently active session (1480186e) now correctly shows its checkpoints in the Web UI. However, all other historical sessions still show empty checkpoint lists.

This suggests the checkpoint index is only built/refreshed for sessions that are active at the time of gateway restart, but historical session checkpoint indexes are not reconstructed.

Evidence:

• Session 1480186e (active during restart): ✅ Shows checkpoints in UI
• Session 55ba12f0 (10 checkpoint files on disk): ❌ Empty in UI
• Session c2a92ba0 (5 checkpoint files on disk): ❌ Empty in UI
• Session dec7ece9 (3 checkpoint files on disk): ❌ Empty in UI
• Total: 23 checkpoint .jsonl files exist on disk across 5 sessions, but only 1 session's checkpoints are visible in the UI

Possible root cause: Gateway startup does not re-index checkpoint files for inactive/historical sessions. The checkpoint-to-session mapping may only be populated when a compaction event fires during an active session, and is not persisted or rebuilt from the filesystem on restart.