PR #42 merged: feat(pack): analyse the camera proxy when the manifest declares one

Closes the crunch side of StuMason/roll#13.

What

Roll (now on main) keeps the full-res camera.mp4 on the recording Mac and ships a small proxy encode (camera.proxy.mp4, 854×480 @ 600kbps) in the pack, declared as a camera.proxy block in the manifest. Crunch only needs analysis pixels, so PackManifest now prefers the proxy file over camera.file when one is declared.

• Same capture, same clock: cameraSyncOffsetMs and all shared-clock seek math apply unchanged.
• Falls back to camera.mp4 for older packs (no proxy block, or an empty proxy.file).
• Proxy path collapses to a basename like every other manifest filename (no traversal).

Why the proxy matters

A real 14.6-min take produced a 625MB camera.mp4 vs a 63MB proxy — the proxy is what makes camera-bearing packs shippable at all (Cloudflare caps /pack uploads at ~100MB, and PackController at 300MB).

Verification

Uploaded that real take to prod with the proxy standing in as the camera track (job oqlrKdXj) — CLIP presence analysis runs fine on 480p frames; results being verified on StuMason/crunch#41.

Tests

• proxy declared → cameraFile = camera.proxy.mp4
• no proxy block / empty proxy file → falls back to camera.mp4
• hostile proxy path (../../etc/passwd) → basename only

🤖 Generated with Claude Code