feat(camera): tilt a whole shot in 3D with one shared vanishing point

[LeadcodeDev]

Refs #362 — part 1 of two. Part 2 is split out, see below.

The gap

style.depth drove parallax: translation and zoom. To tilt a whole shot you copied the same rotate_x/rotate_y keyframes onto every group — and each group then got its own vanishing point, which reads as cards turning independently, not as a camera. Camera keyframes rejected it outright:

unknown camera keyframe property 'rotate_x'

What it does

"camera": {
  "perspective": 1400,
  "keyframes": [
    { "property": "rotate_y",
      "values": [{ "time": 0, "value": -16 }, { "time": 2, "value": 16 }],
      "easing": "ease_in_out" }
  ]
}

The projection is applied once, about the camera's origin — that is the whole difference from the per-group workaround. The rotation is scaled by each direct child's style.depth, the same rule parallax and camera.focus already follow, so a plane at depth 3 swings three times as far as one at depth 1.

Rendered at 0.0 / 1.0 / 1.9 s with rotate_y animated −16° → +16°: tilted one way, flat, tilted the other — and the deep pink plane visibly swings further than the shallow blue one.

Built with css_perspective_m44 and pre_concat, the same machinery per-node rotate_x already uses, rather than a second hand-rolled projection.

Verification

Four tests. Two fail without the tilt. Two assert equality and pass both ways on purpose, which is the point:

• a_camera_tilt_of_zero_renders_exactly_as_no_camera — a camera declaring perspective but no tilt must not move a pixel, because every scenario written before this declares neither
• a_deeper_plane_swings_further_than_a_near_one — the depth-scaling rule, measured as ink displacement
• perspective_zero_is_an_orthographic_tilt

KNOWN_CAMERA_PROPERTIES had to learn the three names; the validator rejects an unknown keyframe property by design, and caught them before any render did.

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

Part 2 is split, not skipped

Camera motion blur means accumulating several sub-frame renders along the camera's motion within a shutter window. That lives in the encode loop, not the paint pass — a different subsystem, a different cost model (k× render time per frame), and a different set of tests. Bundling it here would make one PR that is really two.

I am leaving #362 open for it rather than closing on part 1.

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