perf(agents): parse activity records once per snapshot - #1449

Problem

requestWork runs inside per-message-row activity selectors: ActivityAccessory's hasWork and MessageRow's useThreadAgents. The agent activity store notifies subscribers synchronously on every admitted observer frame, about once per agent per second. Each requestWork call reaches requestActivity, which runs three passes over the agent's data:

1. activityRecords JSON.parses every retained record of each agent active in the channel.
2. It pretty-stringifys each matching batch child.
3. It parses each of those children again.

Both selectors return primitives, so React bails out, but only after that work runs. The cost therefore scales with loaded rows × retained records × frame rate. It only applies while the viewed channel contains an active agent's records. Because the tree stays mounted, it also continues while the window is hidden.

Change

Snapshot record arrays are frozen and replaced whenever records change. requestActivity now caches the parsed agent/channel projection in a WeakMap keyed by that array, so all rows share one parse per snapshot. Request matching, turn selection and terminal classification are unchanged and still run per call. The cache is released together with the snapshot.

Evidence

Setup

• Packaged release bundle (tauri build --bundles app) on a disposable macOS 26.6 VM (6 vCPU), with an owned local relay and a generated identity.
• 8 synthetic agents. Each, in its own channel and per second, sends one NIP-44 observer batch frame (12 children × 900 B) and a working-typing event every 3 s. It also sends a message every 15 s.
• Per-process CPU comes from proc_pid_rusage deltas, covering the native host, the WebKit WebContent, GPU and Networking processes, and WindowServer.
• Typing latency is measured from the OS key post to the next presented frame (150 keys). Channel switch is measured from click to rows.

Reconciliation

• Every generated event was reconciled against relay acceptance, app socket delivery and relay persistence where applicable.
• Across 11 rounds: 36,740 observer frames, 12,243 typing events and 2,453 messages.
• Zero rejected, zero unacknowledged after drain, and zero undelivered.

Attribution

• Interleaved ablations on one binary: base ×3, plus ×2 each of 1 Hz activity tick off, plugin catalog poll off, agent runner tick off, and requestWork short-circuited.
• Only the requestWork ablation moved foreground cost.
• With 8 agents it cut WebContent CPU from 32.5% to 13.9% of a core while viewing an active channel, and from 27.6% to 8.7% while hidden.
• It cut typing p95 from 95 ms to 33 ms.
• With requestWork ablated, the viewed active channel cost the same as a quiet-channel control (13.3%).

A/B

• This change was compared with the same probe build without it, alternating builds over 3 rounds each, under the same workload and with the same reconciliation (zero rejected, unacked or undelivered).

WebContent CPU, as % of one core (means):

• Total app CPU (WebKit and native) with 8 agents viewed: 38.8% → 23.4%. Hidden: 31.4% → 15.5%.
• Typing p95: 94–108 ms → 27–33 ms.
• Channel switch p95 with 4 agents: 161 → 91 ms.
• The quiet-channel and idle controls are unchanged: 13.1% vs 13.3% and 0.8% vs 0.9%. IPC is identical at 10.2 invokes/s.
• While visible, native and WindowServer CPU rise slightly (8 agents: +1.3 and +3.9 points). Their combined total with the app still drops from 51.8% to 40.3%.

Validation

• src/bundled/agent-activity/request-activity.test.ts: a new case asserts that repeated requests against one snapshot parse no further records, and that a newer record array is not served stale. Without the change it fails (12 parses vs 4); with the change it passes.
• pnpm typecheck, design:typecheck and design:check pass. biome check passes on changed files.
• Local full vitest run was not green: 30 of 10,922 tests timed out at 5 s while the machine was under parallel load. All 14 affected files pass when rerun, but that rerun does not establish a full pass, so hosted CI is the package receipt. Hosted CI is green. One WebKit browser-journey shard failed once in agent-search-chat.spec.mjs (agent search choices, a path that does not touch activity parsing) and passed on rerun. Locally the test passes 22/22 under --repeat-each.
• Packaged-app workflow on both builds: an agent request in the viewed channel with a linked turn (turn_started carrying triggeringEventIds, 20 s of activity, then turn_completed). In both builds the request row shows the working accessory during the turn and clears it after completion. An earlier, completed request is not re-associated.