iter6 candidate I: enrich with YouTube avc1 telemetry

Re-tested the iter5-amend binary on YouTube with Enhancer for YouTube
forcing h264 (avc1). Captured a richer failure pattern:

- Multiple cap_pool_init events (4 decode attempts on one tab)
- Zero seccomp violations (Track F still GREEN under YT load)
- "Unable to set control(s): Invalid argument" — VIDIOC_S_EXT_CTRLS EINVAL
  on one of SPS/PPS/SLICE_PARAMS/DECODE_PARAMS/SCALING_MATRIX (cannot
  identify which without per-control TRY isolation, which iter5
  sweep d3a299b removed)
- "Unable to queue buffer: Invalid argument" — VIDIOC_QBUF EINVAL

The S_EXT_CTRLS EINVAL is the more diagnostic of the two — points
to a compound H.264 control payload mismatch between Firefox's libva
path and what mpv-vaapi-copy sends.

Updated iter6 candidate I:
- Added the YouTube failure pattern alongside the bbb pattern
- Step-1 of diagnostic plan: reinstate per-control TRY isolation
  temporarily (do not commit; diagnosis-only)
- Cross-reference with FFmpeg v4l2_request_h264.c per existing memory
- Reproducibility: now 100% on YT-avc1 OR bbb-h264

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

phase0_findings_iter6.md

@@ -71,9 +71,26 @@ The campaign's original substrate question — "make multi-planar libva work end
 
 **Why this is a new candidate, not a Track A regression**: mpv `--hwdec=vaapi-copy` decoded 2000 frames clean on the same iter5-end driver build (sha `4bed52ec5d44b389…`). Only Firefox triggers the EINVAL. So the bug lives in the Firefox-specific consumer path through libva, not in the per-frame request_fd/DPB logic that iter4 closed.
 
-**Diagnostic plan**: strace the Firefox Utility process during initial VIDIOC_QBUF, capture the exact `v4l2_buffer` struct payload, compare against what mpv-vaapi-copy sends at the same call site. Likely culprits: surface handle lifecycle differences (Firefox uses VAImage / VAExportSurfaceHandle paths mpv doesn't), VABufferType ordering (Firefox might submit slice data before SPS/PPS in some frames), or zero-copy DMA-buf attach state.
+**Failure modes observed (iter5-amend telemetry, 2026-05-05)**:
+```
+bbb_1080p30_h264.mp4 (single decode attempt):
+  v4l2-request: cap_pool_init: 24 slots ready
+  v4l2-request: Unable to queue buffer: Invalid argument
 
-**Reproducibility**: 100% on `file:///home/mfritsche/fourier-test/bbb_1080p30_h264.mp4` with `LIBVA_DRIVER_NAME=v4l2_request` env vars + iter5-amend Firefox 150 + sandbox enabled.
+YouTube avc1 (Enhancer for YouTube forcing h264, multiple decode attempts on same tab):
+  v4l2-request: cap_pool_init: 24 slots ready  (×4)
+  v4l2-request: Unable to set control(s): Invalid argument
+  v4l2-request: Unable to queue buffer: Invalid argument
+```
+
+The S_EXT_CTRLS EINVAL is the more diagnostic signal — one of the compound H.264 controls (SPS/PPS/SLICE_PARAMS/DECODE_PARAMS/SCALING_MATRIX) is being rejected by the kernel. iter5 sweep removed the iter4 per-control TRY isolation (`d3a299b`); reinstating it temporarily (or strace) is iter6 step one.
+
+**Diagnostic plan**:
+1. Reinstate per-control VIDIOC_TRY_EXT_CTRLS isolation in v4l2.c (the iter4 diagnostic that pinpointed which compound control fails). Do not commit; use only for diagnosis.
+2. Strace the Firefox Utility process during decode init. Capture exact `v4l2_ext_control` payloads. Cross-reference with FFmpeg's `v4l2_request_h264.c` (cached at `references/ffmpeg-kwiboo/`, the empirical authority per memory).
+3. Once the offending control is identified, look at how Firefox's libva path constructs it differently from mpv-vaapi-copy. Likely: a header field Firefox doesn't populate, an order-of-operations difference, or a VAImage / VAExportSurfaceHandle side effect that perturbs driver state.
+
+**Reproducibility**: 100% on either `file:///home/mfritsche/fourier-test/bbb_1080p30_h264.mp4` OR YouTube avc1 (with enhanced-h264ify or Enhancer for YouTube forcing h264) + `LIBVA_DRIVER_NAME=v4l2_request` env vars + iter5-amend Firefox 150 + sandbox enabled.
 
 **Risk**: medium. Could be a 5-line fix in v4l2.c QBUF prep, or could surface a fundamental Firefox-vs-mpv divergence in libva surface management.