fix(parity): builder, ground shadow, gizmo wrapper, wordart, doc demos

[apresmoi]

Summary

Six interactive surfaces broke during the Three.js parity sweep (#60) — none caught by the test suite. All share the same root cause: the renderers post-parity speak world units in world-axis order (and the camera's zoom is px-per-world-unit), but a handful of call sites still spoke the old CSS-pixel/CSS-axis dialect.

• Builder placement + zoom. placeMeshOnFloor returned CSS-pixel positions in CSS-axis order; the unitless zoom slider was passed directly to the camera (rendered at 0.006× CSS scale); projectScreenToWorldGround inverted 1/zoom instead of BASE_TILE/zoom. Mirrored gallery's LEGACY_ZOOM_COMPAT pattern, flipped placement to world units in world-axis order, and fixed the inverse scale.
• React + Vue ground shadow lifted by the mesh. The per-mesh shadow SVG is mounted inside .polycss-mesh, which now translates by position * BASE_TILE. Pre-parity that was effectively a no-op; post-parity it lifted the shadow by the mesh's world Z, so it landed at the cube's vertical midpoint instead of the floor. Compensated by subtracting meshPosZ * BASE_TILE from the projection target's Z.
• Gizmo wrapper position (all three renderers). The wrapper was emitting translate3d(position[0]px, position[1]px, position[2]px) for what's now a world-unit / world-axis vector — gizmo sat near scene origin instead of on the mesh. Apply the world→CSS axis swap + ×BASE_TILE in all three renderers.
• Vanilla translate-drag math. applyAxisDelta was adding a CSS-px t directly to a world-unit position at the wrong index. Divide by SCENE_TILE_SIZE and write to WORLD_AXIS_FOR_CSS[cssAxis]. Same fix for the plane-drag callback.
• Vanilla rotation gizmo. Each ring now rotates around the world axis it visually wraps (was the CSS-axis index, so the wrong axis spun), snapshots the start position, and re-translates each tick so the visible bbox center stays fixed — matches Three.js's pivot-around-center feel without forcing callers to pre-center via loadMesh({ center: true }). gizmoPosition applies the current rotation to centerOffset so the gizmo follows the spinning mesh. Single global sign flip to match the screen-drag direction users expect.
• WordArt zoom. Same shape as the builder — fitZoom * zoomScale is a unitless CSS-scale value; multiply by BASE_TILE at the camera boundary.
• Doc PolyDemo lighting. PolyDemo.astro was writing light-direction / light-ambient / light-color attributes on <poly-scene>, but the element reads directional-direction / ambient-intensity / directional-color. The demo's lighting config was silently ignored on every docs page, falling back to renderer default intensity 1 (very dim under the post-parity physical-Lambert /π shading). Renamed the attributes and bumped the default to intensity: 4.5, ambient: 0.55 (gallery's defaults). Generator-mode path also splits state.light into directionalLight + ambientLight for the imperative API.

Test plan

• /builder — place several primitives, verify they snap to the click point and stack on top faces; floor shadow stays at floor; Z-gizmo sits on the mesh
• /wordart — renders at the same on-screen size as pre-parity
• /gallery with Mesh selection + Scene interactive enabled — gizmo centers on the selected mesh; translate arrows track the mouse; rotation rings rotate around the visible center in the dragged direction
• /guides/projections/ — the tree GLB now renders bright (was very dark)
• Spot-check the other docs PolyDemos (/quickstart, /core-concepts, /guides/{performance,shapes,textures}/) for the new lighting defaults