Add per-frame up vectors to camera tracks

[slimbuck]

Camera tracks (--camera-track) rendered every frame with the fixed --camera-up vector, so a multi-frame render could not tilt or roll the camera. This adds an up vector to each track pose.

The plain frames-list format now accepts an optional up: [x, y, z] per frame, interpolated between frames by normalized lerp so it stays unit-length when neighbouring frames differ in direction. Frames without one fall back to --camera-up, mirroring how frames without a fov fall back to --camera-fov. loadCameraTrack gains an optional third defaultUp argument (world +Y when omitted), so the library API stays additive.

The supersplat editor's project poses and the viewer's animation tracks carry no up vector or roll, so those formats keep a constant up from --camera-up. Adding roll there would need a change to the editor and viewer formats first.

The image writer transforms each pose's up into data space alongside its position and target, as the start/end segment path already does. CLI help and the README document the new field.

Verification: a new test/camera-track.test.mjs covers per-frame up, mid-frame normalized lerp, the default fallback, malformed up rejection, and the editor/viewer formats using the default. End-to-end, a track frame with up: [1,0,0] renders byte-identical to a single render with --camera-up 1,0,0, and a frame without up renders byte-identical to the default-up single render.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.