perf(sessions): session picker re-reads every live transcript in full and search parses all 2,150 files per query #735

Symptom

Opening the session picker or typing in its search freezes the main process. src/main/sessionIndex.ts:

• listRecentSessionsWithPrompts discovers every Claude transcript and every Codex rollout (stat per file: 248 + 1,902 files on this machine), sorts by mtime, and for the top limit (10) calls extractPromptsFromFile, which readFiles the whole transcript, split('\n')s it and JSON.parses every line. The cache is keyed on mtime, and the ten most recent transcripts are by definition the live sessions whose mtime changes every few seconds — so every open is a cache miss for all of them. Today those ten files total 122 MB (one Codex rollout alone is 89 MB), read, split into millions of sliced strings and parsed on the main thread, to show 4 prompts per session.
• searchSessionPrompts iterates all candidates (2,150 files, including a 148 MB rollout) and calls the same full extraction for each before scoring — on every query.
• promptCache is a module-global Map with no eviction; every transcript ever listed or searched stays in it with its full prompt list.

Expected

• Listing should read only what it needs: the newest few prompts of a transcript live in its tail, and both providers' files are append-only, so a cache entry should extend by the bytes appended since the last read instead of re-reading from byte 0.
• Search should parse incrementally too, so repeated queries cost the delta, and should not touch thousands of files per keystroke.
• The cache should be bounded.

Impact

Multi-second main-thread freezes (every pane's screen and IPC stall) each time the picker opens or a search query changes, proportional to the size of the live sessions — i.e. worst exactly when the user has been working longest.

Refs #103, #93, #96.