[brsbl]

What was wrong

Clip export encoded repeated screenshots when Chrome could not capture at 30 fps. The regression reproduced 33 distinct frames out of 210 on Mac and 141 on Linux.

What changed

• Advance page animation by 1/30 second per captured frame, independent of rendering and encoding speed.
• Replay waits and asynchronous actions on the same clock; freeze and seek CSS animations for each frame.
• Decode moving content and require 90% distinct frames plus the correct position in every frame.

How you verified

• Baseline regression failed on both platforms.
• Final-head Mac/Linux acceptance passed: all four clocks produced 210/210 distinct frames at expected positions.
• Full Slop Cop on the final head: no P0/P1 findings; one P2 follow-up for child-frame animation, Playgrounds clips: advance animation clocks in child frames #516.
• Final-head broader CI passed: 41 successful checks; publishing is deferred until merge.
• Full isolated bb e2e passed on this head with the exact CI build: HTML and Anatomy exports, saved-state restoration, asynchronous action replay, missing-prompt/native-card errors, readable end credits, and 210/210 distinct decoded moving frames. Replayed values were 9 and 2; the source state remained 7. QA crop/CLI fixture corrections were verified against the actual exports; no product changes were needed.

Top-level page animation is deterministic; media playback, worker clocks and animated child frames (#516) are outside this contract. Rendering can take longer than the clip duration on a slow host. The final three-second credit frame is intentionally held.

Reviewed head: 722f4837dda96ab00fb20e5df7c5ff4703ecf0e5; base: 4155bd1646920415fa465470ef7b1fb75051ac4b. This changes headless export timing; decoded frame positions and the retained MP4s are the temporal evidence.

Closes #514
Follow-up to #512 and the R3 spec tracked by #513. The washing-machine proof follows #508 and remains local.

BB-Thread-ID: thr_wgcdsffskf