test(engine): write HDR fixture color tags into the H.264 VUI

[miguel-heygen]

What

Tag the synthetic HDR test fixture's color metadata directly in the H.264 bitstream (h264_metadata BSF) instead of relying on the encoder to propagate the -color_* CLI flags into the VUI.

Why

Tests on windows-latest (Windows render verification) has been red on main and on every code PR since #2377 merged. #2377 correctly narrowed HDR detection to the transfer function (PQ/HLG) — BT.2020 primaries alone are not HDR — but the SDR→HDR extraction tests synthesize their fixture with -color_trc smpte2084 and depend on the encoder writing that into the bitstream. The pinned Windows CI ffmpeg build drops the transfer on that path, so the fixture probes as SDR there, no SDR→HDR preflight runs, and both tests fail with hdrPreflightCount 0 (expected 1). Linux/macOS builds propagate the flag, which is why only Windows went red — and #2377's own Windows run was cancelled by a rapid main push, so it merged without ever seeing it.

How

One change in synthHdrTaggedClip: add -bsf:v h264_metadata=colour_primaries=9:transfer_characteristics=16:matrix_coefficients=9 (bt2020 / PQ / bt2020nc). The BSF writes the VUI into the SPS itself, so the probe reports color_transfer=smpte2084 regardless of encoder negotiation. The existing -color_* flags stay for container-level tagging.

Test plan

• bunx vitest run src/services/videoFrameExtractor.test.ts in packages/engine: 67/67 pass locally (both previously failing SDR→HDR tests included).
• Verified the mechanism in isolation: encoding with the BSF and no -color_* flags still probes as color_transfer=smpte2084, proving the tag no longer depends on encoder passthrough.
• The real gate is this PR's own Tests on windows-latest run — it fails on main, so green here is the proof.

Not covered

• No product code changes; fix(render): require HDR transfer metadata #2377's detection behavior is untouched.
• The Windows ffmpeg build's flag-dropping behavior itself (upstream/toolchain, not ours).