Fix three renderer perf metrics that lied, and the bug they hid

[frenchie4111]

Summary

This branch started as "two telemetry fields report constants" and ended up finding the renderer bug those constants were hiding. Four changes, in the order they happened.

1. reactCommits / reactTotalMs were structurally 0 in every packaged build. React's production build compiles out enableProfilerTimer, so <Profiler>'s onRender is never called — react-dom-client.production.js contains zero occurrences of onRender. "reactCommits":0 appeared in 100% of ~1,823 samples across two log files and was never once nonzero.

2. heapUsedMB and its deltas are quantized and up to ~20 minutes stale. Chrome caches performance.memory on pages that aren't cross-origin isolated. Observed pinned at exactly 560.8 for 40 minutes across 617 samples (9 distinct values in an entire log) while real RSS swung 600MB inside 30 seconds — so heapGrowthMB / heapReclaimedMB cannot show the allocate-and-collect sawtooth they were added to catch. Replaced in [snapshot] with real per-process rendererRssMB / rendererCpuPct via app.getAppMetrics(), scoped to BrowserWindow webContents. The performance.memory-derived fields are kept but suffixed …Quantized.

3. rendererBlockingMsPerSec was not per second. It logged the bucket's raw blockingMs. That bucket is nominally 1 s but stretches without bound when the renderer's timer is starved — a DevTools heap snapshot produced a single ~104 s bucket, surfacing as blocked=103792ms/s. Reading those totals as rates overstates blocking by 20-100x. Now normalized by elapsedMs, with rendererBucketMs and rendererBlockingMsTotal logged alongside so the raw numbers stay recoverable.

4. One terminal's status change re-rendered every mounted worktree. This is the bug the constants were hiding, and the reason the app got progressively laggier over a session.

App keeps every worktree mounted. The whole statuses / shellActivity maps were threaded from App down through WorkspaceView → SplitRenderer → LeafPane → TerminalPanel. A status event fires per streamed token, and each one allocated a new map — so with ~22 worktrees open, every token re-rendered all N subtrees even though 21 of the 22 statuses were unchanged.

Fixed in three dependent steps:

• Narrow the reads. New per-id selectors useTerminalStatus(id) / useShellActivity(id) mean the maps are no longer props anywhere in that chain. Both return a primitive or a stable ref, so useSyncExternalStore's Object.is check dedupes and only the tab that actually changed re-renders.
• Stabilize the callbacks App passes down — inline arrows allocated N new closures per App render.
• Memoize WorkspaceView. Only sound after the first step; while the maps were props their identity changed every token and this would have been a no-op.

The profiling alias, and why it is now opt-in

Change 1 originally landed as a permanent react-dom/client → react-dom/profiling alias. That was reverted to opt-in (HARNESS_REACT_PROFILING=1) in a5ca2c9, and the reversal is the most transferable thing on this branch.

React 19.2's profiling entry emits a performance.measure() per component render to populate the DevTools Performance track. In a 36 s trace of a loaded session, logComponentRender was 10.8% of total renderer CPU — the largest named entry after idle and (program) — with logComponentEffect and the performance.now() calls feeding them on top, plus 21k retained PerformanceMeasure objects in a heap snapshot taken while nothing was recording.

So: instrumentation added to explain a slowdown became a measurable share of it. Default builds now ship reactProfiling: false on every sample, and every consumer renders n/a — never 0, which is what caused the original misreading.

Honest note on measurement

The lag accumulates over hours, so there is no synthetic repro and no clean A/B. What we have is a maintainer running the merged build for a couple of days and reporting a large improvement. That is a real signal but it is not a number, and the baseline it is measured against included our own profiling overhead from change 1's first form. Some of the improvement is this branch getting out of its own way rather than change 4 working. Both are worth having; they should not be conflated.

Notes for review

electron.vite.config.ts carries a long comment for a reason — do not add a bare react-dom alias. react-dom-profiling.profiling.js itself does require("react-dom") to reach ReactDOMSharedInternals, so aliasing the bare specifier points that lookup back at the profiling build; the cycle leaves the internals undefined and the app dies at startup on reading 'd'. The alias is also an anchored regex rather than a plain string, because alias find matches on a / prefix and 'react-dom' would additionally rewrite react-dom/server.

CLAUDE.md is updated with all three telemetry defects, the anti-pattern behind change 4, and the general rule: a telemetry field that reads a constant is not evidence of a quiet system, it is evidence of broken instrumentation. Including the cheap check that would have caught two of these in seconds:

grep -oE '"field":[0-9.]+' perf.log | sort -u

Test plan

• npm run typecheck clean
• npx electron-vite build clean
• npx vitest run src/renderer src/shared — 1504 tests pass
• Controlled experiment on change 1: identical source, two production builds — no-alias reports commits:0, aliased reports commits:6
• Mixed-graph check (bare-react-dom createPortal + a second createRoot) returns {"commits":6,"buildIsProfiling":true,"portalOk":true,"secondRootOk":true} — confirms the cycle hazard above is avoided
• Default build contains zero occurrences of logComponentRender; HARNESS_REACT_PROFILING=1 build contains 5
• Soaked in a maintainer's daily-driver build for two days

🤖 Generated with Claude Code