Speed up thread rendering while content streams

[SawyerHood]

Human comments

What was wrong

While an agent answer streams into a long thread, every newline-gated text update triggers a timeline refetch, React commits, a Markdown re-render and a layout, and on a large database that path was expensive at every layer. Profiling production builds found four root causes. First, the @container/page scroll port sat in an implicit auto grid row, so every layout evaluated the page container twice and the 100cqw table breakouts restyled every timeline row: about 11.5 s of a 21 s stream at 1× CPU. Second, Markdown re-parsed the whole message and rebuilt highlighted code DOM on every update. Third, the timeline controller committed extra intermediate renders per update. Fourth, the server rebuilt the latest timeline page from scratch on each refetch (event queries, grouping context, JSON decode), and daemon event ingest did avoidable work.

What changed

Client

• bottom-anchored-scroll-body.tsx: explicit grid-rows-[minmax(auto,1fr)] on the timeline scroll grid. Geometry is unchanged.
• Markdown: a stable dangerouslySetInnerHTML object for highlighted code (DOM nodes added per stream went from 15k to 2k on the default scenario), an LRU for highlights, a thread-mention precheck, and stable empty candidate arrays.
• useThreadTimelineController: no re-render on fetch start or end once rows exist, one consistent commit per data update, and a stable side-chat send-to-main callback (useSendSideChatMessageToMain).
• ThreadTableOfContents: per-row label cache.
• markdown-incremental-pieces.ts (the block memoization technique from Streamdown): assistant messages parse each settled piece once. Reused pieces are re-cloned so components re-render on the same schedule as before, cold mounts parse the whole message once, and messages with footnotes or definitions fall back to single-document parsing. Message directive mounts now come from context. Markdown fence and list scanning helpers are shared with streaming-markdown-split.ts.

Server and database

• packages/db/src/data/events.ts: INDEXED BY hint for the parented-boundary EXISTS (4 to 5.6× faster on tool-heavy threads).
• Ingest: skip search-segment parsing for delta rows, look up completed turns directly, and send small daemon event replies uncompressed. The JSON payload is unchanged and no wire fields changed, so HOST_DAEMON_PROTOCOL_VERSION stays the same.
• Incremental latest-page reads: a per-thread event rewrite generation (bumped by every event mutator and sweep, checked together with PRAGMA data_version), a grouping-context cache, an exact stored-event decode cache, and a latest-page selection memo that is reused only at the latest sequence of an active thread.
• docs/debugging-and-qa.md: documents the new timeline-streaming-memo.test.ts corpus gate.

About 2k of the added lines are product code, 5.7k are tests, and 1.7k are Markdown fixture documents used by the incremental Markdown tests.

Not in this PR (each would change visible behavior and needs a decision): snapping timeline growth while streaming, desktop content-visibility for offscreen rows, skipping refetches on ticks with no visible text change, paced refetches or server-side frame coalescing, excluding delta rows from the event budget, and one Markdown container across the settled/tail seam.

How you verified

Benchmark: measured with a streaming render benchmark that ran production builds on a seeded database (1,200 threads, ~400k events) plus 150- and 600-turn threads, driving headless Chrome for Testing 149 at 1440×900. Runs interleaved base and candidate builds; medians of 5 iterations at 1× and 3 at 4×, measured on the previous base 1a7c008643. The final message text hash and timeline geometry hash matched the base in every iteration of every scenario. The harness is not part of this PR; it is in this PR's first commit (f16f089991) if anyone wants to rerun it.

Scenario	Main thread	LoAF blocking	Frame p95	Line latency p50 / p95	Server CPU	Timeline GET p50
default (16.5 KB into 150 turns)	20.8 → 10.9 s (−48%)	214 → 0 ms	50 → 16.8 ms	376 → 276 / 491 → 319 ms	6.1 → 3.6 s	25 → 9.9 ms
long (66 KB)	44.8 → 29.5 s (−34%)	3,882 → 5 ms	100 → 16.8 ms	477 → 276 / 658 → 329 ms	11.3 → 7.8 s	27.6 → 10.7 ms
pathological Markdown	26.3 → 15.0 s (−43%)	239 → 21 ms	50 → 16.8 ms	417 → 280 / 513 → 341 ms	7.6 → 4.8 s	26.5 → 10.1 ms
600-turn thread	20.4 → 12.0 s (−42%)	317 → 0 ms	33.4 → 16.8 ms	460 → 284 / 610 → 335 ms	11.2 → 4.4 s	75 → 10.4 ms
default, 4× CPU	—	9.6 → 2.6 s	266 → 117 ms	805 → 481 / 1,199 → 634 ms	−19%	—
long, 4× CPU	—	28.4 → 7.1 s	467 → 133 ms	1,131 → 545 / 1,820 → 685 ms	−17%	—

Style recalculation dropped 79–86% at 1×. Retained JS heap after GC is 0.5–4.8 MB higher (bounded piece cache and highlight LRU).

Behavior

• Every change was written test-first with fail-before proofs, plus old-vs-new differential tests. Changes whose differential tests showed observable differences were dropped, for example a stable loadOlderTimelineRows identity, a timeline controller provider, and an API key verification cache.
• A later simplification pass removed tests and simplified a few helpers. Independent reviewers found no behavior change in the product code. For every removed or merged test, a mutation reintroduced its bug; where no remaining test failed, the test was restored and re-proven.
• Provider corpus: row snapshots written from main 267938526d and compared against this branch with row-snapshots.test.ts: 340 threads, 106,510 rows, 0 diffs. The new timeline-streaming-memo.test.ts appends streaming rows tick by tick to every corpus thread and requires each warm latest-page build to equal a build on a fresh connection with empty caches: 340 of 340 threads pass.
• Markdown corpus check: every unique assistant message in the corpus (14,200) rendered through the incremental and single-document paths at every streaming step: 199,978 comparisons, 0 DOM differences.
• Dev app on this branch: streamed a 16.5 KB document into a 150-turn thread on a seeded database. It rendered completely, stayed pinned to the bottom, and logged no console errors.

Commands (on 267938526d with this branch)

• pnpm exec turbo run typecheck lint --filter=@bb/app --filter=@bb/server --filter=@bb/db: pass. oxfmt --check on changed files: pass.
• pnpm exec turbo run test --concurrency=1 --filter=@bb/app --filter=@bb/server --filter=@bb/db: @bb/app 526 files (4,556 tests), @bb/server 2,637 tests, @bb/db 514 tests. All pass.
• pnpm install --frozen-lockfile: pass; the lockfile is unchanged from main.

AGENT GENERATED