Bound long-thread outline and timeline work

[amadad]

Summary

• keep the full-thread conversation outline stable during high-volume streaming events
• overlay only assistant rows newer than the outline revision from the loaded timeline, preserving live TOC text without rebuilding full history
• retain one outline revision per thread with cross-thread LRU eviction
• preserve conservative invalidation for structural, completion, and unknown events
• bound app timeline pages to eight conversation segments across prefetch, latest/delta, fallback, and older-page fetches without changing the public API/CLI default

Root cause

Every agent/plan delta invalidated the full conversation-outline query. On long threads, each synchronous SQLite read, JSON decode, and full event projection took hundreds of milliseconds on the server's single Node event loop. New deltas arrived while that work was in flight, creating a near-continuous rebuild loop that stalled all browser and daemon requests.

After removing that server loop, browser profiling found a separate mount cost: the app rendered 55 rich timeline rows and about 5,300 DOM nodes in one main-thread task. The server already supports cursor pagination, but the app inherited its broader public default.

User impact

Streaming text remains live in the table of contents, but token/progress updates no longer trigger full-history outline work. Structural and completion boundaries still refresh the authoritative outline once.

The app initially mounts eight recent conversation segments and loads older history through the existing cursor. The full outline remains available for TOC navigation. The server, SDK, and CLI continue to default to 20 segments.

Validation

• outline-focused regressions: 64/64
• app pagination regressions: 13/13
• full server suite: 1,328/1,328
• full app suite: 2,165/2,165 collected tests; one unchanged workspace-resolution suite did not collect locally (react/jsx-dev-runtime)
• app and server typechecks
• app lint, Prettier, and git diff --check
• real-browser long-thread mount: 55 → 22 rows, 5,297 → 3,615 DOM nodes, 697 ms → 274 ms long task
• two independent reviews approved both the outline/cache behavior and the app-only pagination boundary

Stack

This draft is stacked on #900 (fix: bound timeline cache revisions). Once #900 merges, this PR's diff will reduce to the two commits owned here.

[amadad]

@SawyerHood Follow-up profiling after #898 exposed two remaining costs on the same long thread: repeated full-outline rebuilds during streaming and mounting too many rich timeline rows.

	Before	After
Mounted timeline rows	55	22
DOM nodes	5,297	3,615
Mount long task	697 ms	274 ms

Streaming text and the TOC remain live. #900 is the small cache prerequisite. Would you sanity-check the outline invalidation boundary and app-only eight-segment page limit when convenient?

[SawyerHood]

Hey @amadad I have a few extra followups that I'm working on for perf for the timeline right now! Might be best to not try to focus too much on this right now.

The timeline projection is pretty mission critical and I've had to be really careful to not break behavior while working in it!

[amadad]

All good!