iter5 amendment verified: Track F GREEN, new iter6 candidate I

Patched libmozsandbox.so (sha 4e6c7d58…, +1824 bytes vs iter5-G)
deployed to ohm via temporary HTTP server on boltzmann:18080
(vpn route was closed; ohm has lan route to boltzmann.fritz.box).

Sandbox gate is fully open. With LIBVA_DRIVER_NAME=v4l2_request +
sandbox enabled + bbb_1080p30_h264.mp4, Firefox 150 emits:
  v4l2-request: cap_pool_init: 24 slots ready
  v4l2-request: Unable to queue buffer: Invalid argument
vs pre-amendment which had the seccomp violation +
"Unable to allocate media request: Function not implemented"
between those two lines. Track F closes GREEN.

YouTube test (watch?v=7DAPd5MGodY) didn't engage v4l2_request
because YT negotiated VP9/AV1 with FF150 (no h264ify); v4l2_request
only handles H.264. Codec-negotiation issue, not sandbox issue.

New iter6 candidate I documented: Firefox VIDIOC_QBUF EINVAL on
first frame is consumer-specific (mpv-vaapi-copy clean at 2000
frames on same driver). Diagnostic plan and repro included.

phase8_iteration5_close.md: appended Track F GREEN evidence +
post-amendment status table + iter6 candidate referral.

phase0_findings_iter6.md: added candidate I (Firefox QBUF EINVAL),
listed under recommended pairings as strong iter6-lock candidate.

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

phase0_findings_iter6.md

@@ -65,6 +65,18 @@ The campaign's original substrate question — "make multi-planar libva work end
 
 **Plan**: find an MPEG-2 test fixture, decode via mpv vaapi-copy + vainfo. Verify hantro G1's MPEG-2 path through libva-v4l2-request-fourier. Surface any codec-specific bugs (the iter4 DPB+request_fd fixes were H.264-specific; MPEG-2 has different control flow).
 
+### I. Firefox VIDIOC_QBUF EINVAL on first frame (NEW from iter5 amendment 2026-05-05)
+
+> The iter5 amendment (Utility seccomp fix) closes Track F: sandbox no longer blocks the V4L2 request API. With sandbox open, Firefox loads the v4l2_request driver, `cap_pool_init: 24 slots ready` succeeds, then a single `Unable to queue buffer: Invalid argument` (VIDIOC_QBUF EINVAL) on what looks like the first frame, after which Firefox falls back to SW.
+
+**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.
+
+**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.
+
+**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.
+
 ### G. V4L2_MEMORY_DMABUF (carried from iter2+3+4+5)
 
 > Replace V4L2_MEMORY_MMAP with userspace dma-buf allocation (iter2 Fix 3 was statistical / LRU mitigation; this is architectural).
@@ -87,6 +99,7 @@ The campaign's original substrate question — "make multi-planar libva work end
 - **E alone** (perf binding cell) — anchors campaign-wide claims to numbers. Carried five iterations.
 - **F alone** (MPEG-2) — validates beyond H.264 scope.
 - **G alone** (DMABUF) — high-risk architectural.
+- **I alone** (Firefox QBUF EINVAL) — narrow, deterministic repro, gates the only known consumer-with-iter5-amendment hard-failure. Strong candidate for the iter6 lock.
 
 ## State that carries (re-verified iter5 close)