[6/7] Refuse or correct the exports the browser gets wrong

[dazzatronus]

A host falls back to a cloud render whenever an export throws, but it can't see a video that comes out wrong without an error. A review of the whole stack found the remaining ways that happens; each is now either correct or a refusal:

• the edit or playback changing mid-export rejects;
• rich text and captions finish drawing before each frame is read, so their first frame doesn't flash the finished text;
• luma mattes drawn from video are refused (luma);
• muted outputs export no audio; range and scaleTo are refused;
• cropped video keeps its crop, and video players are recognised in minified builds;
• an audio or speech clip whose audio can't load rejects with assets;
• AAC encoding is checked up front, and long exports are budgeted by size as well as duration;
• one export runs per edit, and a cancel wins over other errors.

About 740 lines, two thirds tests; each fix is its own commit.

#	PR	Adds	Why separate
1	#224	exportBlob as the export engine	The new API
2	#225	Pre-flight issues; fail on placeholders	Routing depends on it
3	#226	Off-screen frames	Stops the page jumping
4	#227	Clip speed in frames and audio	Its own fix
5	#228	Size and bitrate from the edit	Its own fix
6 (this PR)	#229	Refuse or correct the remaining wrong exports	Found in the whole-stack review
7	#230	Release 2.25.0	Mechanical

Verify: npm run verify:ci; in a browser: a rich-text typewriter clip's first frame, keys and scrubs during an export, crop parity, video versus image lumas, a Firefox export with audio, a muted output, and a 4K five-minute edit.
Risk: browsers without an AAC encoder (Firefox, Linux Chromium) refuse any edit with a video clip, so hosts render those in the cloud; rich-text exports take about two text draws per clip per frame longer.