feat(paint): style.material and a scene light

[LeadcodeDev]

Closes #355 — its second half. #356 already landed the depth of field.

The decision I said this needed

I held this back because it needed a lighting model chosen, which is a product call. Here it is:

A scene-level light with a sensible default, plus material on the node.

What makes a tile read as rendered is not the highlight on its own — it is that several shapes are lit the same way. A per-node baked preset cannot agree with its neighbours about where the light is. But requiring every scenario to declare a light would be friction for a generator, so:

• "material": "glossy" alone works, and assumes upper-left — where an eye expects it without being told
• scene.light overrides it for everything in the scene at once

"scenes": [{
  "light": { "x": -0.4, "y": -0.85, "intensity": 1.0 },
  "children": [
    { "type": "div", "style": { "background": "#6D28D9", "border-radius": 28,
                                "material": "glossy" } }
  ]
}]

Three layers, three presets

A radial highlight on the lit side, a specular edge along it, a soft shade opposite — all three derived from one direction vector.

Preset	Highlight	Specular edge	Shade
glossy	broad, bright	marked	soft, opposite
metal	tighter, dimmer	harder	deeper
matte	none	none	the only layer

matte exists so a flat surface can sit beside glossy ones without looking unlit: it takes light and returns none.

"material": { "preset": "glossy", "intensity": 0.6 } doses one node. The node's intensity is multiplied by the scene's, so light.intensity: 0 flattens a whole scene without editing any node.

The direction convention, and the bug the tests caught

x/y point toward the light, not along its travel — the natural reading of "negative is on the left". I got it backwards first, and the test said so:

the default light is upper-left, so the upper-left of the tile must be
clearly brighter than the lower-right: lit=98.0, shaded=167.0

The boundary, and why it decides layout

The material follows the node's box, clipped by border-radius and by clip-path. It is not clipped by what a shape component draws, because shape paints its own geometry and the paint pass has no access to it.

So a sphere is a div with border-radius: "50%", not a shape: circle whose material would spill into the corners of its bounding square. An octagon is a clip-path polygon. Give the silhouette to the box — the rule file leads with that rather than burying it.

Verification

Six tests. Five fail without the paint call. The sixth asserts equality and passes both ways on purpose:

• a_node_without_a_material_is_untouched — intensity: 0 is byte-identical to no material at all
• glossy_is_brighter_on_the_lit_side_than_opposite_it
• turning_the_light_around_turns_the_gradient_around — a light from the lower-right lights the lower-right; this is the coherence the whole design is for
• matte_shades_without_a_highlight — lit side must not brighten, far side must darken
• the_scene_light_intensity_scales_every_material_at_once
• a_material_never_paints_outside_its_clip_path

Rendered check: four tiles on one scene — glossy, metal, matte, and glossy on a border-radius: 100 box that reads as a sphere — all lit consistently from upper-left.

cargo fmt --all --check, cargo clippy --workspace --all-targets -- -D warnings, cargo test --workspace (1582) all clean.

What it deliberately is not

No cast shadows between elements, no occlusion, no inter-reflection. It is a per-node surface treatment, not a renderer. Separating planes is depth of field's job (#356), which reads the same style.depth.

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