🤖 perf: instrument chat-switch latency (server replay phases + switch-to-first-message) and add a perf scenario

[ThomasK33]

Problem

On xum server, switching from one running chat to another sometimes shows a skeleton for several seconds before any messages appear. A research pass (2026-09-25) found the mechanism:

• The renderer hides cached rows while the switch is hydrating (cachedTranscriptStale, WorkspaceStore.ts ~1735-1745 and ~2465-2471; ChatPane.tsx ~603-618) until caught-up arrives or a 10 s deadline passes.
• The server sends nothing until replayHistory finishes (src/node/orpc/streamBridge.ts ~107-167).

There is no measurement of the real per-phase costs, so we can't rank the causes on a real server or prove the planned fixes (A: show cached rows on incremental returns; B: progressive replay and keepalives). This issue adds that measurement. It is step F of F → A → B.

Scope

1. Server replay timing. For each onChat replay, record the phase durations: file-lock wait, history read and parse, prior-history fingerprint, emitting history rows, in-flight stream replay, and total time to caught-up. Also record the rows and bytes sent, the replay mode (full or since) and any downgrade reason. Emit one structured log line per replay; use log.debug, or a higher level only above a threshold, e.g. >1 s. Reuse existing timing helpers if suitable. No new persisted state.
2. Renderer switch timing. Using performance.mark/measure or an equivalent that e2e tests can read, time from setActiveWorkspaceId to (a) the first transcript row painted, (b) caught-up, and (c) the skeleton shown and hidden. Keep the overhead negligible, with no new UI.
3. Perf e2e scenario. Add tests/e2e/scenarios/perf.chatSwitch.spec.ts (or similar): two workspaces, B with a large history, both streaming via mock AI. Switch A → B → A → B and record in-page milestones: reuse tests/e2e/utils/pageMilestones.ts from 🤖 tests: record in-page perf milestones for workspace open #4456, and extend it if the switch needs different selectors. Write them to perf-summary.json so the nightly Perf Profiles workflow collects them. The scenario must show the skeleton window on the switch back to a mid-stream chat. Assert only a generous upper bound, so it isn't flaky.

Acceptance

• One server log line per replay with the phase breakdown. Verified by a test on the timing wrapper's behavior, not on log text.
• Renderer marks exist, and the new perf scenario records them.
• make test-e2e-perf passes locally, including the new scenario.
• A before-numbers table in the PR body (median of ≥5 runs) that A and B will compare against.

Constraints

Instrumentation and measurement only: no behavior change to gating or replay. Follow AGENTS.md (no manual memoization, log helper). Refs the research report in the perf-owner workspace; see the follow-ups for A and B.

---

Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high

[linear-code]

MUX-216

[ThomasK33]

Done in #4543, merged to main as b9cb54b.

What landed

• Server: one onChat replay log line per replay (src/node/services/onChatReplayTiming.ts). It carries totalMs, phasesMs, historyBytesRead, streamReplayed, and the row counts. The level is debug; replays of 1 s or more log at info.
• Renderer: User Timing measures xum:chat-switch:{skeleton-shown,skeleton-hidden,first-row,caught-up}, each measured from xum:chat-switch:start (set in setActiveWorkspaceId).
• Scenario: tests/e2e/scenarios/perf.chatSwitch.spec.ts writes chatSwitch into perf-summary.json.

To regenerate the table: run the spec with --repeat-each 6 --workers 1 (serial runs matter), then run bun scripts/perf/chatSwitchTable.ts artifacts/perf/electron.

Before-numbers (medians in ms; 6 runs × 3 rounds, 18 switches per column; local Electron at 9545a1a)

metric (median)	cold-open-small	cold-open-large	switch-back-small	switch-back-large
renderer.clickToStartMs	19.2	10.5	70.8	98.6
renderer.skeletonShownMs	32.6	25.4	26.6	22
renderer.caughtUpMs	416	398	197.5	176.3
renderer.skeletonHiddenMs	506	491.3	248	272.3
renderer.firstRowMs	515.3	500.3	264.6	302.1
dom.firstRowFromClickMs	532.8	509.9	329	386.2
dom.longestTaskMs	67	112	95.5	134.5
server.totalMs	331	350.4	152.1	147.9
server.historyLockWaitMs	308.1	252.5	68.4	0
server.partialReadMs	3.2	1.5	52.8	41.5
server.historyReadMs	19.9	45.3	5.7	59.7
server.fingerprintMs	0.1	3	0.2	4.2
server.olderHistoryCheckMs	1.9	16.4	–	–
server.emitRowsMs	0.5	1.9	0.2	0.2
server.initReplayMs	0.5	1.5	0.5	0.8
server.sentRowCount	24	180	2	2
server.historyBytesRead	31530	922550	32322	923344

For #4505 (A) and #4506 (B)

• Switch-back: the skeleton shows for about 220–250 ms (shown ~25 ms → hidden ~250–270 ms). About 150 ms of that is the server replay, which is file I/O while the streams keep writing (partialRead plus lock wait or history read). Delivery to the store takes 30–45 ms, and render the rest.
• Click to switch: a switch-back spends 70–100 ms between the click and setActiveWorkspaceId, compared with 10–20 ms on a cold open. This time comes before the start mark.
• Cold open: historyLockWait (250–310 ms) dominates.
• Large epochs (remote UAT, a synthetic 164 MB epoch): since replays took 1.6–1.9 s, of which historyRead was ~1.2 s and fingerprint 0.38–0.56 s. Since mode still reads and fingerprints the whole epoch.
• Gap: mock AI can't replay a stream mid-flight, so the scenario doesn't measure streamReplay (tracked in 🤖 tests: support mid-stream replay for mock AI streams so the chat-switch scenario measures streamReplay #4542; B needs it). A real model does exercise it (streamReplayed: true).
• For A: flip EXPECT_SKELETON_ON_MID_STREAM_SWITCH_BACK in the spec.

---

Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high