perf(history): initial history load parses the whole transcript to return its last 120 entries #747

Symptom

Restoring a workspace at boot spends ~10 s of main-thread time parsing whole transcripts to show their last 120 entries.

Evidence (today's run): 25 historyLoader.loadInitialChunk spans read 252 MB in 10.7 s of main-thread time; the worst — an 89.3 MB / 18,366-line rollout — took 4,618 ms to return 120 entries, and 332 ms even from page cache later. All 25 ran in the first 8 s of boot, when main's event-loop p99 hit 577 ms and nine parallel Claude spawns each showed 950–2,130 ms of non-provider time (session.spawn.total p50 1,065 ms vs providerStart p50 58 ms). Renderer workspace.history.loadInitial totalled 38.7 s including queueing behind INITIAL_HISTORY_CONCURRENCY = 2.

Mechanism

src/main/sessions/historyLoader.ts:87-121 (readInitialTranscriptTail) iterates streamJsonl (readline + JSON.parse per line, src/shared/runtime/streamJsonl.ts:37-63) over the whole file, interning fields and keeping a ring of limit; totalEntries is the line count. readOlderTranscriptWindow does the same forward scan.

Expected

A reverse tail read: read blocks backwards from EOF, split on newlines, parse only until limit complete records are found (guarding the partial first line); count totalEntries with a raw newline scan of the buffer (no decode, no parse) or lazily. Same for the older-history window. Keep parse-error tolerance, the intern pool, and hasMore semantics.

Impact

89 MB load 4.6 s → tens of ms; boot main-thread parse ~10.7 s → well under a second, which also shrinks boot-time session:recover (p50 1.2 s) and spawn contention.

Refs #87 (streaming parser), #103, #93.