feat(3d): project a grid onto a curved surface, and a dot_map globe

[LeadcodeDev]

Closes #387. Refs #388.

dot_map as a globe

projection: "orthographic" turns the flat map into a sphere. The visibility test is the part a clip-path: circle can never do — it has no notion of a sphere underneath, so it cuts a disc out of a flat map and shows the far hemisphere straight through.

• far-hemisphere culling from cos_c
• rotate.lng / rotate.lat to aim it, with a linear sweep
• limb_shading darkening towards the edge
• great-circle arcs by 3D slerp, not linear lat/lng interpolation — which would not follow a great circle. Each sample is re-projected and visibility-tested on its own, so an arc crossing the horizon is cut into visible segments rather than drawn through the planet, and one entirely on the far side paints nothing.

The world dot grid switches from fixed pixel spacing to fixed angular spacing at orthographic scale, so screen spacing converges towards the limb by construction rather than by a fudge.

layout-surface on a container

The grid is laid out flat by taffy, then each cell is projected onto a cylinder or sphere with one perspective shared by the container — the shared vanishing point that per-node transform cannot give. It reuses css_perspective_m44 and the pre_concat idiom apply_plane_camera established in #400, applied per child instead of per plane.

layout_pass.rs was not touched, and that is the right answer rather than an omission: like transform and perspective, this is purely paint-time. taffy_bridge.rs never reads those either.

cylinder has no arc_y field at all — compiler- and schema-enforced, rather than a shared struct with a field that is silently inert. That is the lesson from #339, #349 and #364 applied at the API level.

Depth ordering is a stated limitation, not a silence. Children still paint in declaration order. For the intended use — a patch well under 180°, a dome of cards where every cell faces the camera — that is fine. A wide arc, or enough rotate_y to swing a cell past the limb, can make it paint over a nearer one. #93 owns depth sorting generally and is untouched; the rule file and the type's own docs say so.

A false-positive test, caught and fixed

dot_spacing_converges_towards_the_limb passed under the stub at first: float noise made edge_gap 13.888888888888868 and centre_gap 13.888888888888888, so a naive < was satisfied by rounding alone. Requiring a real margin (edge < centre * 0.9) made it report centre=13.889px, edge=13.889px and fail correctly.

Worth recording as a general point: a bare < between two floats that are mathematically equal is not a regression guard.

Verification

18 new tests, each proven red by stubbing the projection:

assertion failed: orthographic_project(0.0, 170.0, 0.0, 0.0).is_none()
an arc entirely on the far hemisphere must be culled, not drawn through the globe
depth must recede monotonically away from the centre: mid=0.0 edge=0.0
a projected grid's cells must not all be the same width: centre_gap=90.00px, edge_gap=90.00px

Backward compatibility pinned both ways: a dot_map with no projection field and a container with no layout-surface render byte-identically.

cargo fmt --all --check, cargo clippy --workspace --all-targets -- -D warnings, cargo test --workspace (1740) all clean. An end-to-end scenario mixing both features validates and renders.

One thing to know for later

Both SurfaceAngle and the globe's RotationAngle are small self-contained Fixed | Animated{from,to} types evaluated locally from the frame time — not wired into the shared keyframe pipeline, because animator.rs was owned elsewhere while this was built. If a general hook lands there, these two ad hoc mini-animations are the first candidates to be unified into it.

Written comment-free, per the codebase-wide rule from #345.