test(hdr-regression): tighten Window F maxFrameFailures budget after Chunk 4 fix (#375)

## Summary

Tighten `hdr-regression` Window F `maxFrameFailures` from 5 → 0 now that Chunk 4 (matrix3d support + scene initial-state) has landed.

## Why

Window F (transform + scale + border-radius on the video itself) was the remaining known-fail in the `hdr-regression` suite, baked into the golden so the suite stayed green while Chunk 4 was outstanding.

After Chunk 4 fixed `parseTransformMatrix` (matrix3d support) and the shader-transitions initial-state, re-running the suite shows **0 failed frames** against the existing golden — the encoder is byte-deterministic, and Window F's GSAP rotation/scale happens to emit 2D `matrix()` rather than `matrix3d()`, so the same golden is still correct after the fix. Tightening the budget catches any drift in the layered HDR compositor immediately.

## What changed

- `tests/hdr-regression/meta.json`: `maxFrameFailures` 5 → 0 (matches `hdr-hlg-regression`).
- `tests/hdr-regression/README.md`: Window F row + Fix history section updated to reflect the new state.

## Test plan

- [x] `bun run test --filter hdr-regression` — passes with 0 failed frames at the new budget.

## Stack

Follow-up to Chunk 4 (transform & clipping). Reviewable separately so the budget tightening is decoupled from the code fix.

packages/producer/tests/hdr-hlg-regression/README.md

@@ -27,13 +27,6 @@ The suite is intentionally short (5 s, two windows) — it exists to detect
 regressions in the HLG-specific code path, not to enumerate every composition
 shape (those live in `hdr-regression`).
 
-## Tolerance
-
-`maxFrameFailures` is **0** here. HLG is a pure pass-through path — no known
-failures, no transcoder workarounds — and HEVC encoding against the rendered
-`rgb48le` buffer is byte-deterministic on the same fixture. Any drift is a
-real regression, not codec noise, so the budget is the strictest possible.
-
 ## Fixture
 
 `src/hdr-hlg-clip.mp4` — last 5 seconds of a user-recorded HEVC HLG clip,