chore: INFRA-306 Leading control for the breathing-circle 60fps budget

[MP2EZ]

Closes INFRA-306 (Layer A). Scoped down by /b-batch; the device-measured half is INFRA-309.

What this is — and explicitly is not

Not a frame-rate measurement. Every CI job is ubuntu-latest and cannot render a frame; Maestro has no ms/fps assertions either (crisis-button-reachability.yaml:34-35 says so in-file). What ships is a structural proxy that fails when the PERF-01/PERF-02 regression shape (ff591f3a) returns to the breathing animation path.

Saying that plainly is the point. MAINT-307 had just finished correcting two docs claiming these budgets were "enforced on-device via the Maestro flows" when they were not — a doc asserting a control that doesn't exist is worse than a documented gap, because it stops anyone building the real one.

Deliverables

1. Removed a fabricated metric. RenderingOptimizer.getJSFrameRate() / getUIFrameRate() returned 58 + Math.random() * 4 and 59 + Math.random() * 2 under a "Mock implementation - in real app, use native bridge" comment. They fed FrameMetrics.jsFrameRate / .uiFrameRate, which grep confirms were write-only — never read in src/ or __tests__/, on an event with no listeners. So no live gate asserted on random numbers; the trap was prospective, for whoever was next told to "wire up the existing UI frame rate." Both getters and both fields removed; module header now records why this file must never become the 60fps control (it samples the JS thread via a requestAnimationFrame loop — the exact pattern PERF-02 removed — and is reachable only from a demo component).

2. Added app/scripts/check-breathing-worklet-purity.js, wired into the Performance regression job as npm run check:breathing-worklets. Fails on: runOnJS or a React state setter inside a useAnimatedStyle / useDerivedValue / useAnimatedReaction body; requestAnimationFrame on the animation path; BreathingCircle losing React.memo or its module-scope DEFAULT_PATTERN / DEFAULT_PHASE_TEXT.

Deliberately not flagged, because a guard born red gets loosened rather than obeyed:

• runOnJS inside withTiming completion callbacks (BreathingCircle.tsx:172,184-185) — once per cycle leg, and precisely the pattern PERF-02 replaced the bad one with. Flagging it would ban the fix.
• The 1s hold-pattern countdown setInterval (:217) and the 100ms inter-cycle setTimeout (:285).
• cancelAnimationFrame — teardown, not sampling.

All three exclusions are pinned by negative tests, so a later "tightening" can't quietly reintroduce them.

3. Documented the boundary in post-launch-monitoring-runbook.md §5a: what the proxy covers, what it does not, and why 60fps is the wrong unit for INFRA-309 — ProMotion nominal is 8.3ms, not 16.67ms, so a UI thread holding a steady 60fps on a 120Hz device is dropping half its frames while passing an fps >= 55 floor. The budget must become a dropped-frame ratio against measured nominal refresh.

Verification

npm run precommit green end-to-end; lint:baseline → No new lint errors. 555/558 errors across 173 files.

Tests: 16 passed, 16 total   ← guard detection logic
Tests: 10 passed, 10 total   ← npm run test:performance (the CI job)

The control actually fails (AC1 says FAILS, not merely reports) — injecting runOnJS into the real useAnimatedStyle body:

❌ Breathing-worklet purity check failed:
  BreathingCircle.tsx:100 — runOnJS inside a useAnimatedStyle body. That hops the
  bridge on every frame (the PERF-02 regression).
exit=1

Clean source: exit=0.

Note for review

.gitignore:159's check-*.js scratch-script sweep silently swallowed both new files. Unnoticed, this PR would have wired CI to a script absent from the repo. Whitelisted with the same per-file pattern MAINT-154 and INFRA-177 used.

CLAUDE.md's Validation Matrix still reads Breathing 60fps | Nothing and is now stale — .claude/ isn't tracked on development, so that correction is a separate chore(.claude): commit on _bare.

🤖 Generated with Claude Code