fix(viewer): kick render on focus and visibility resume

[mvanhorn]

What does this PR do?

frameloop="never" makes FrameLimiter's requestAnimationFrame loop the only render driver. Browsers throttle rAF when the tab is hidden, the window is unfocused, or the system marks the tab as occluded. When that happens advance() stops firing and the canvas stays whatever was last in the swap chain (blank on first paint, or the previous frame on subsequent freezes).

This adds three event listeners alongside the existing rAF loop. visibilitychange (transitioning to visible), window focus, and pageshow each call advance() synchronously so the next visible frame matches the current scene state without waiting for rAF to resume.

The fix is contained to packages/viewer/src/components/viewer/frame-limiter.tsx (+21/-0). No new imports. No layer-boundary changes.

Fixes #275
Closes #196

Why prior fixes don't cover this

• fix: recover viewer post-processing after duplicate scene mutations #228 rebuilds the post-processing pipeline on duplicate-scene mutations
• fix(viewer): skip post-processing pipeline when WebGPU is unavailable #234 short-circuits the pipeline when navigator.gpu is undefined
• fix: WebGPU renderer race on Canvas remount & duplicate item scale loss #284 caches the WebGPU renderer per canvas to avoid Canvas-remount races

None of those address rAF throttling. Once the throttle hits, every render path stalls because useFrame only runs when advance() is called.

How to test

1. bun install && bun dev, open the editor in Chrome or Firefox.
2. Click the Pascal tab into focus. The viewer renders.
3. Switch to a different tab for 5 seconds, then switch back to Pascal.

Without the fix, the viewer can stay frozen (blank or stale) until you move the mouse over the canvas. With the fix, the viewer renders the current scene immediately on tab return.

A second reproducer: open Pascal in a focused tab, drag another window over Pascal so it occludes the canvas, then move that window away. Some Linux WMs (and Zen on Windows) trigger the same rAF throttle that this fix recovers from.

Screenshots / screen recording

Before/after recorded locally on macOS Chrome 147 in the chrome MCP harness, which holds document.visibilityState === 'hidden' so the throttle path fires reliably. Frame 1 is the broken state on reload (blank canvas, faded toolbar). The click triggers a focus event, the new handler calls advance(), the scene renders.

Checklist

• I've tested this locally with bun dev
• My code follows the existing code style (bun check passes)
• I've updated relevant documentation (if applicable) - n/a, the inline comment in frame-limiter.tsx documents the rationale
• This PR targets the main branch

[mvanhorn]

Before/after recorded locally on macOS Chrome 147 in the chrome MCP harness, which holds document.visibilityState === 'hidden' so the throttle path fires reliably.

Frame 1 is the broken state on reload (blank canvas, faded toolbar). The click triggers a focus event, the new handler calls advance(), the scene renders.