Resume is slow for large legacy sessions due to duplicate full-history processing

Problem

Resuming some large legacy sessions can take 10–20 seconds or more from selecting the session in the resume picker to a usable composer.

I added temporary timing instrumentation to a local fork and observed the following for one legacy session:

• 18,795 persisted rollout items and about 219 turns
• Server history reconstruction: 7.9 seconds
• Client initial transcript hydration: 4.9 seconds
• Complete client bootstrap: 14.7 seconds
• Configuration loading and thread creation were comparatively small (tens to hundreds of milliseconds)

The client requests excludeTurns=true, but the server still reconstructs the full legacy history to initialize the resumed model. The client then separately reads and hydrates the transcript for display, so the same large history is effectively processed twice before the composer is ready.

Suggested improvements

These are proposals based on the timings above; I have not implemented or tested them yet. I will update this issue after testing them in my fork.

1. Keep the full history available to the resumed model, but return/display only a bounded initial transcript page.
2. Make older legacy transcript content load lazily when the user scrolls upward.
3. Reuse the server-side parsed history or an indexed/projection representation instead of reparsing the same rollout for client display.
4. Migrate legacy rollouts to the paginated/thread-store representation in the background, or maintain a durable parsed/indexed projection.

The first improvement should reduce time-to-ready most directly, while the latter options should reduce the server-side parsing cost.

Environment

This was observed with a local amended build based on Codex alpha code. The measurements came from /home/.../.codex/logs_2.sqlite; no user prompt contents are included here.