The 19 bake-off clips all shipped with the photosensitivity warning sitting on
top of the visuals. PLN: "lol all clips have the epilepsy warning on top of the
viz xD and all seem to have very low fps, like maybe 5 ?"

Extracting a frame showed one cause behind all three symptoms: the warning modal
itself; the app's full UI chrome still visible (FX rail, top bar, shortcut strip)
because the modal swallowed the "minimal performance shell" click and the `h`
keypress; and the apparent ~5 fps, because ~90% of every frame was static chrome
behind a dark scrim while 17.6 frames/s were captured faithfully. The frame rate
was never the problem — I had measured it correctly and drawn the wrong picture
of what was being measured.

Seeding localStorage does NOT suppress it: hexa installs a dev-only bridge that
persists localStorage to disk through the dev server and calls
`hydrateLocalStorageFromDisk()` at boot, overwriting anything an init script
seeded. Verified by trapping `Storage.prototype.setItem` and reading the stack —
the write came from `localStorageBridge.ts:150`. So use the app's own control:
uncheck "Show this warning at startup", click OK, which writes through the bridge
and flushes to disk.

PARTIAL, deliberately. The new guard now throws rather than capturing, and on the
next run it caught a SECOND modal behind the first: "START A SESSION". So the
bake-off clips were not slow — the scene had never started. Committing the guard
alone because it is strictly better than silently shipping 19 more scrims, and
refusing loudly is the behaviour worth having even before the fix is complete.

Still to do (see the task board): a `git pull` brought 50 commits that also
inverted the mode semantics — `?studio=1` is now stripped and Studio is the
DEFAULT, with `?live=1` opting into the full-bleed performance shell; Studio
freezes shader time when `studioTransportActive === false`, which is the other
half of "no motion"; and the "Minimal performance shell" button this script
clicks no longer exists at all.