Summary

Local resume and fork pickers currently wait for the filesystem-backed scan-and-repair lookup before showing sessions, even when the State DB can provide an indexed first page immediately. This change uses that indexed page to make the picker interactive sooner while preserving scan-and-repair as the authoritative result.

For local workspaces, the initial load now:

• reads the first page from the State DB and displays those rows as provisional;
• continues the existing scan-and-repair lookup in the background;
• replaces the provisional page with the repaired page, preserving the selected thread by ID and reevaluating search and pagination; and
• keeps the indexed rows without a continuation cursor if reconciliation fails.

Picker page, preview, and transcript RPCs run as independently tracked tasks. This lets provisional transcript actions proceed while reconciliation is pending. Closing the picker aborts and drains those client tasks before shutting down its dedicated app-server session, instead of waiting for reconciliation to finish first.

Selecting a provisional row validates only that rollout before resuming or forking. The validation uses the same bounded rollout summary as filesystem listing and rechecks that the path is discoverable under active sessions, the thread ID still matches, and the current provider, source, cwd, and typed-search filters still accept the authoritative metadata. Search validation also preserves the State DB title and Git branch overlays that the reconciled row would display.

The loading, provisional-state, reconciliation, validation, and focused tests now live in tui/src/resume_picker/loading.rs and tui/src/resume_picker/loading_tests.rs instead of extending the already-large picker module.

Remote workspaces keep the existing direct scan-and-repair behavior. This reduces initial display latency; it does not reduce the total filesystem work performed by reconciliation.

Testing

• just test -p codex-tui resume_picker (103 tests)