What

Hardens the runtime lifecycle from #5967 so it holds up on real compositions, in preview and in renders.

• Device pixels. The capture and output canvases and the compositor's buffers follow the page's scale (a render's injected scale wins over a devicePixelRatio that fell back to 1), so a 2x or 4k render is not blurred at half resolution.
• A render never gives up mid-video. A frame whose capture throws is plain DOM and the next frame wraps again (counted in failedFrames, logged once per 25). In Studio preview, three capture exceptions in a row turn blur off for the session. Paint timeouts, which render plain and never end blur, are handled since feat(core): capture motion blur runtime lifecycle #5967; here failedFrames also counts capture exceptions. A tab that stops painting while the clock keeps running (hidden or minimized) used to turn blur off for good after about 6 s.
• A hidden preview tab rests on plain DOM. While document.visibilityState is hidden the preview does not wrap and requests no paints (a hidden tab delivers none); blur resumes when the tab is visible again. Engine mode is unaffected.
• Timeline callbacks stay out of the scan. The mover scan and its restore seek always suppress events, so tl.call() callbacks no longer fire during discovery even with data-motion-blur-events="on"; only the sub-frame pose reads honour -events.
• Wrapping the root no longer disturbs the page. Wrap and unwrap move the root in the document; each move now runs through the runtime's record filter (host.ignoreMutations) and the adapters re-seek at the current time right after it. Measured before the fix (Chrome 152, 6 play/pause cycles): CSS animations restarted at 0 for one displayed frame on every unwrap, and the runtime's MutationObserver read each move as a composition change (18 stage-size and 12 timeline posts instead of 2 and 1).
• Studio preview holds the playback seek while a blurred frame is in flight, so the poses and both captures belong to the same time and a fast box keeps its full width. init.ts gets a small hold (the transport skips a playback seek while a blurred frame is busy; the next tick catches up), with its own test.
• adapters/waapi.ts (shared runtime code, a small separate hunk): after a wrap Chrome cancels the moved element's CSS animation and starts a new one, and the adapter kept reviving the cancelled (idle) one. The adapter now drops an idle animation, only when it is browser-created (CSSAnimation / CSSTransition); script-created animations are left alone. Please review that hunk on its own: it is the one change here that affects every composition, not only blurred ones.
• The host exposes now() for the re-seek.

Why

Part 3 of 9 in the capture motion blur stack: #5875 → #5967 → #5968 → #5969 → #5970 → #5971 → #5990 → #5991 → #5992. It builds on #5967.

Stack goal: opt-in capture motion blur for compositions, in Studio preview and in renders, drawn with Chrome's html-in-canvas. The correct frame is always preferred over a blurred wrong one: when the capture cannot be trusted for a frame, that frame renders sharp from the plain DOM.

Notes

• Blurred preview frames update at half the display rate: a two-phase frame needs two paints, and the transport holds its seek until the frame completes. The pixels are correct; the rate is the cost.
• An iframe in the root still reloads when the root is wrapped; the defect list that blocks blur for it is feat(core): block capture motion blur on html-in-canvas defects #5971.
• Limits unchanged from feat(core): capture motion blur pose, discovery and compositor #5875 and feat(core): capture motion blur runtime lifecycle #5967 (trails over foreground elements, a halo on transparent movers, trails leaking past overflow:hidden, 2D flips through scaleX = 0 blend as rotation, a fast child inside a parent that moved earlier is not blurred).
• Nothing in this PR changes a composition that does not set data-motion-blur="on", except the waapi.ts hunk above.

Testing

• captureMotionBlur/index.test.ts: wrapping and unwrapping (including the quiet-then-re-seek order and no re-seek when there is nothing to unwrap), the two-phase frames, painting and unwrap-on-pause, the render fallback, the hidden-tab rest, the opt-in switches that moved here from feat(core): capture motion blur runtime lifecycle #5967 (shutter clamp, a browser without drawElementImage, the reason logged for a root that asked for blur, a nested capture canvas, opting back out, a composition where nothing moves; the paint-timeout tests now live in feat(core): capture motion blur runtime lifecycle #5967), the callback spy for the scan, device-pixel canvases, and the guards that survived a deliberate break (exactly three failures, no seek below zero, unwrap() removes the hide rule, canvases and hide attributes, invisible movers are not blurred; each was shown to fail with its mutation applied).
• compositor device-pixel test in composite.test.ts; init.blurHold.test.ts for the preview hold; adapters/waapi.test.ts for the narrowed idle skip.
• bun run build, core tsc --noEmit, and the core runtime tests pass; comment ratchet against feat(core): capture motion blur runtime lifecycle #5967's branch passes; core stays under its size budget.

🤖 Generated with Claude Code