fix(skills): handle HDR video outro inputs

[doodlewind]

Summary

• make ffprobe scalar probes robust for side-data-heavy iPhone/Dolby Vision clips
• detect HLG and PQ sources and perceptually tone-map them to BT.709 SDR before compositing
• explicitly convert the Chrome-rendered sRGB card layers into BT.709 and tag the H.264 output
• document the HDR requirements and color-metadata verification command

Root cause

The CSV ffprobe output used by the script can append an empty field for streams with HDR side data, so values such as 1920 arrived as 1920, and failed numeric parsing. After that parsing issue was bypassed, the graph still mixed sRGB card pixels directly into HLG code values and emitted 8-bit H.264 tagged as HLG, which made the end card colorimetrically incorrect on HDR-aware displays and fragile on common sharing targets.

Impact

Phone footage recorded as HLG/PQ now produces a broadly compatible BT.709 SDR end card video. SDR inputs retain the existing path. HDR inputs on older FFmpeg builds fail with a clear FFmpeg 8+ requirement instead of silently producing a mislabeled result.

Validation

• full 1920x1080 iPhone Dolby Vision/HLG clip rendered end-to-end to a 61.633s BT.709 SDR output
• full audio/video decode with ffmpeg -xerror
• output verified as limited-range bt709/bt709/bt709, H.264 High, yuv420p, AAC stereo, and faststart
• transition sampled at 5 fps; logo, tagline, and URL entrances verified with no clipping or brightness jump
• source audio preserved before the designed fade; final two seconds verified silent
• SDR/no-audio smoke test
• PQ fixture with unknown matrix/primaries verified to fall back safely and emit BT.709
• bun build skills/pocketjs-video-outro/scripts/make-outro.ts --target=bun
• git diff --check