fix(engine): long films show progress during the effect check and never wait minutes on it - #6697

Description

A long film exported from the Desktop app on a Mac can sit at "prepare" for many minutes with no progress, then end with zero frames written. One report: a 670 s, 1080p 60 fps SVG/canvas film with a blur, about 16 minutes at 4%, then "Streaming encoder exited before frame 0 was written". The app reports an export as stalled after 180 s with no progress line.

The cause is the per-frame effect scan from #6318. When a film has a blur, drop-shadow or backdrop-filter element and takes the single-worker macOS GPU path, scanCssEffectLiveFrames seeks every frame of the film in a scratch browser before frame 0 is captured, to find the frames the effect shows on. It prints nothing while it runs, and it stops early only once the effect covers more than 60% of the film. At 6 to 24 ms a seek, a long film spends minutes there.

Two changes:

• Progress. After each 240-frame chunk the scan reports how far it got, and the render prints Checking effects, N of M frames at 25%. The app's stall watchdog counts that line as progress, so a long scan that is still moving is never reported as stalled, and the film keeps perf(engine): fast capture stays on for frames a shadow, blur or clip effect does not touch #6318's faster capture.
• Budget. After each chunk the scan also projects its total time. If the whole scan would take more than 120 s (under the app's 180 s limit), it stops and the render keeps the whole-film screenshot capture it used before perf(engine): fast capture stays on for frames a shadow, blur or clip effect does not touch #6318. That capture is always correct, just slower. So a scan that would truly take too long no longer holds back the first frame.

The in-page chunk loop moved into scanChunk unchanged, and the scan takes an options object, so the scan loop stays within the complexity limits.

Before and after, on a real render

Old Mac (M4 Pro), hyperframes render --workers 1 --gpu --fps 60, a 1080p fixture with 2,000 animated SVG circles and one blurred card on screen for 10 s. 0.8.214 against this branch, one render at a time, each stopped after 300 s:

The 300 s film scans for 103 s as before, now with a line every chunk, and keeps the fast path. The 600 s film starts at once. Its capture is slower, so in a terminal, where nothing reports stalls, that film takes about 16% longer in total than on 0.8.214 (about 1,890 s against 1,630 s, projected from the rates). In the app, the same film is reported stalled after 180 s on 0.8.214. Scanning ahead of capture instead of before it would remove that trade-off, and is the follow-up.

Testing

fails without the fix: stops after one chunk when the whole scan would hold back the first frame too long and reports the frames scanned after each chunk in riskFrames.test.ts. On main the scan seeks all 40,219 frames and returns an empty set (expected Set{} to be null), and no progress is reported.

• riskFrames.test.ts, riskFrameCapture.test.ts, threeDProjection-cssEffectRisk.test.ts: 31 passed; riskFrames.test.ts passed 3 runs in a row.
• tsc --noEmit for the engine and producer packages: clean.

What I did NOT exercise

No export from the Desktop app itself. The app's stall watchdog resets on any stdout line its progress parser accepts, and 25% Checking effects, 240 of 36000 frames is one: a percent of 25 or less reads as Preparing. I checked that by reading the app's parser, not by running the app. The 120 s budget is my choice, accepted by the team: under the app's 180 s limit, and long enough for the 300 s fixture's 103 s scan.