P1: Compute transcript provenance in one pass to avoid streaming UI stalls #1181

Audit #1180, 2026-09-10. Baseline: checkout 9fc8645; fetched origin/main bf6fb02 has identical relevant implementation. This is implementation backlog, not a shipped fix.

Evidence

src/components/ThreadView.tsx loops over every assistant message on each detail change. src/provenance.ts scans back to the previous user message and reparses earlier tool inputs for each assistant. Long autonomous turns do quadratic work. DOM windowing does not bound this computation.

Benchmark of the actual function: one user turn, alternating Read tools/assistant messages, 1,847-character JSON tool inputs, median of five repetitions after warmup:

The largest fixture fits the Store's 1,000-message cap plus 100-message overflow slack. This is synthetic CPU timing, not a desktop frame profile.

Change

Build provenance in a forward pass, accumulating tool evidence once per user turn. Snapshot capped arrays for each assistant so future tools cannot change earlier badges. Reuse existing classifiers. Memoize against actual message inputs instead of the whole detail object.

Acceptance

• Preserve chronological order, six-reference caps, text citations and previous-user boundaries.
• Earlier assistants never inherit future tool evidence.
• Benchmark the three sizes above and show near-linear growth and a substantial reduction at the cap.
• Metadata-only detail updates do not rebuild unchanged provenance.
• Add one regression check comparing semantics and counting tool classifications.

Reproduction: import messageProvenance from src/provenance.ts using Node's --experimental-strip-types. Create one user followed by N pairs of Read tools with input JSON.stringify({file_path:'src/example.ts',description:'x'.repeat(1800)}) and assistant text citing that path. Time the ThreadView loop over all assistant indices for N=125,250,500.

Related #404 introduced badges; #564 bounds DOM, not preprocessing.