perf: wire launch-to-interactive CI budget; verify updateForState deopt still needed

[r3dbars]

Measurement-driven performance pass for the 1.1.49 release, grounded in the existing Premium performance budget + Home recent-captures benchmark and the PRD WS4.2 targets. No speculative changes — every item below is backed by a real measurement on this Apple Silicon machine (Xcode 26.6, swiftlang-6.3.3.1.3).

What I measured (baseline, all green)

Metric	Measured	Budget	Status
Expanded app size	88.3 MiB	220 MB	✅ huge headroom
Resources	2.0 MiB	80 MB	✅
Home recent-captures avg load (1k captures)	20.6 ms	750 ms	✅
Home recent-captures avg load (10k captures)	214.9 ms	750 ms	✅
Home recent-captures cancel ack	~0.1 ms	100 ms	✅
Idle memory (thin build, at rest)	28 MB phys_footprint / 88.5 MB RSS	—	✅ healthy
Launch → interactive (warm, in-process)	~285 ms	<400 ms (PRD WS4.2)	✅ meets target
Launch → interactive (cold)	~600 ms (fresh build ~900 ms)	—	—

Home list transcript re-read (the #1399/#1465 concern): fully solved. RecentMeetingsScanner.loadRecent serves rows from RecentMeetingMetadataCache on the warm path with zero transcript/summary reads (only the live audio attachment is re-resolved, intentionally). The residual 10k-capture cost is the inherent O(N) directory stat+sort to find the 5 newest — 215 ms, comfortably under the 750 ms budget. No change needed.

Fix 1 — Launch-to-interactive is now measured and CI-enforced (PRD WS4.2)

The PRD asks for "app launch to interactive <400ms warm" plus "a perf test to CI that fails on regression." The launch UI smoke already proved the menu bar is functionally interactive (status item + popover + primary actions) but carried no timing, and CI only budgeted model-ready (≤30s), which is a different thing.

• Add launchToInteractiveMs to the launch UI smoke report, measured from the kernel process-start time (kinfo_proc.p_starttime) so it captures true launch latency including pre-main dyld/runtime setup — not just time since the app delegate started.
• Score it in performance-budget.rb (--launch-ui-smoke / --max-launch-interactive-ms) and wire it into CI's existing Premium performance budget step (no parallel harness). build.sh scores it on local builds too, guarded so a skipped smoke doesn't fail the budget.
• Measured: warm ~285 ms — meets the <400 ms warm target. The first CI run measured cold launch at 1420 ms on the GitHub runner, so the CI ceiling is 2500 ms — a firm regression guard (fails on a ~1.8x+ blow-up) with room for runner variance, not a flaky 5%-margin gate.

Fix 2 — updateForState forced-deopt: re-verified still required, kept

The @_optimize(none) workaround was flagged as maybe-obsolete (it cited swiftc 6.3.2; the toolchain is now 6.3.3). I removed the attribute and rebuilt: the identical compiler crash still reproduces on swiftlang-6.3.3.1.3 —

SIL/BorrowUtils.swift:542: Fatal error: cannot get borrow introducers for unknown guaranteed value
While running pass SimplifyCFG on SILFunction "OverlayRootView.updateForState(...)"

So the workaround stays. I also confirmed it is not a hot path: updateForState fires only on discrete overlay state transitions (FloatingOverlayController.pushStateToViews), never per audio frame — the per-frame meter path calls headerView.updateWaveformLevel directly. So the deopt costs nothing measurable. Refreshed the comment to record the 6.3.3 re-verification so the next person doesn't re-test blindly.

Verification

• Full build.sh (-O -whole-module-optimization) builds clean with the workaround; crashes without it (attribution isolated in a separate rebuild).
• performance-budget.rb pass/fail/missing-field/bad-JSON paths unit-checked; over-budget and missing-field exit 1, under-budget exits 0.
• Home-recent benchmark re-run: unchanged (this diff doesn't touch that code).
• check-build-source-lists.py green; build/launch-ui-smoke.json confirmed at the path CI reads.

Scope: measured performance only. No visual/UX or speaker-matching changes (owned by separate threads).

🤖 Generated with Claude Code