perf(ui): oversized single Turn defeats transcript render bounds

[liugddx]

Problem

Scrolling upward into one tool-heavy Turn can stall the Desktop renderer even though the transcript range is otherwise bounded. This is a focused remaining case under #2913 phase 4: a single Turn is the paging, eviction, and CSS containment unit, so one oversized Turn defeats all three bounds at once.

Sanitized evidence

The following are aggregate measurements from a private local workspace. Session IDs, titles, prompts, tool arguments, tool output, user names, and filesystem paths are intentionally omitted.

• Transcript: 8 Turns, 280 stored message records.
• Largest Turn: 170 records and approximately 699k serialized JSON characters.
• Largest Turn composition: 61 tool calls, 58 tool results, and 50 assistant records.
• Assistant payload shape in that Turn: approximately 98.8k reasoning characters and 32 fenced-code delimiters.
• Renderer at rest after navigating into this history: 0% CPU, about 245 MiB RSS, 450.4 MiB physical footprint, and 675.5 MiB peak physical footprint.
• A native sample while idle found the main renderer thread asleep, so this is an interaction-triggered mount/layout/paint spike rather than a background busy loop.

These figures are deliberately content-free and cannot reconstruct the underlying conversation.

Root cause

• Desktop requests a 512 KiB transcript range and normally retains at most 10 Turns.
• DesktopTranscriptReplica.#evictToBudget groups every resident message by Turn and cannot evict the protected anchor Turn. An individual protected Turn may therefore remain resident above the byte budget.
• ChatView renders each Turn as one .maka-transcript-turn subtree.
• content-visibility: auto is applied only to that outer Turn. Once any part of a very tall Turn approaches the viewport, Chromium must activate the whole subtree, including every reasoning block, Markdown response, and tool row within it.

The normal transcript window therefore remains bounded in Turn count but not in mounted/render-active work when one Turn contains a long agentic loop.

Synthetic reproduction

1. Create one Turn containing roughly 50 alternating assistant/reasoning segments and 60 completed tool calls with bounded synthetic output.
2. Add a few small Turns after it and open the transcript at the tail.
3. Scroll upward until the large Turn enters the viewport.
4. Observe the long frame and renderer memory increase as the whole Turn subtree activates.

No production conversation data is required to reproduce the shape.

Desired outcome

Keep Turn identity and transcript paging semantics unchanged, but bound render-active work inside an oversized Turn. Candidate direction:

• derive stable sub-Turn render segments at existing assistant/tool timeline boundaries;
• apply sub-Turn content-visibility/intrinsic geometry or a bounded virtual window so offscreen segments do not require full layout and paint;
• preserve scroll anchoring, disclosure state, text selection, keyboard/screen-reader navigation, and live-tail behavior;
• add a synthetic regression covering an oversized single Turn and upward scrolling.

Normal scrolling should not produce a task over 50 ms for the synthetic fixture.

Relationship to existing work

Refs #2913. The sparse replica and Turn-bounded range are already in place; this issue isolates the pathological single-Turn case that remains before full transcript virtualization.

Prepared by OpenAI Codex under maintainer direction from a read-only, sanitized local audit. The maintainer owns the final technical decisions and submission.

[liugddx]

Synthetic implementation validation (content-free, one local macOS arm64 run):

• Fixture: one Turn, 145 stored records, 736,799 serialized JSON characters.
• Composition: 48 assistant records, 48 tool calls, and 48 tool results, all deterministic synthetic text.
• Gesture: 480 requestAnimationFrame samples while scrolling upward across 25,424 CSS px.
• Result: frame P95 16.6 ms, P99 32.5 ms, maximum 41.8 ms; 0 Long Animation Frames over 50 ms.
• Chromium reported 47 timeline render segments still skipped outside the final viewport.

This is a reproducible regression measurement, not a general release benchmark. No production workspace identifiers, prompts, tool arguments/output, user names, or filesystem paths were used.