Experimental world-transform camera renderer

[DanFessler]

Builds on #1 (Tier 1); merging this also lands #1.

Experimental worldTransform option

While the camera moves, the workspace is laid out once, for a view covering the whole move, and each frame sets one transform on the layer, instead of laying out every panel on every frame. When the camera stops, everything is laid out normally again.

• true / false (default)
• { minPanels: n }: only for moves with at least n panels in view where they start or end, decided when the camera starts moving
• "auto": { minPanels: 40 }. With the CPU slowed 4×, laying out 36 panels per frame kept up and 49 began to stutter.

With 100 panels and the CPU slowed 4×, slow frames during an animated zoom fall from about 40% to under 10%, and during a pinch from about 25% to about 5%.

Trade-offs while the camera moves, documented in docs/performance.md: chrome, text and gaps scale like a picture; zooming in looks slightly soft until it stops; collapsed groups and icon tiles are chosen for the laid-out view.

Also:

• React prop and world-transform attribute on the custom element
• IDE demo: a status-bar button and palette command cycle off / auto / on
• npm run bench takes WORLD=1|auto, SIZES=6x6,8x8 and THROTTLES=4
• Bundle-size figures in the docs updated (core 38 kB gzipped)

Tests

E2E checks for the world transform:

• panels are exactly where the camera puts them on every frame (LTR and RTL; gaps scale with the layer);
• overlay floats stay put;
• a 100-panel move restyles only a few elements per frame;
• the end state matches the normal renderer;
• pinch geometry is correct.

E2E checks for the threshold:

• a light layout stays on the normal renderer;
• moves with 40 or more panels in view use world mode from their first frame;
• panels are counted at the move's ends, not across the whole layout;
• a custom threshold works;
• a move that starts during a layout animation is decided from its start.

The custom-element attribute is covered too.

🤖 Generated with Claude Code