phase0: revise framing — iter1 is unblocked, libva comparison is follow-up validation

Operator pushback: phase 0 should unblock iter1, not gate it. The
locked question is "fix what's locally in scope" — kill the green,
not just identify a layer. The captured wl_dmabuf message is
internally inconsistent on its own (per-plane fds + single-allocation
offset for plane 1 is a contradiction no valid producer can claim
simultaneously). mpv's translation layer produces this regardless of
which producer feeds it, so iter1 can write the fix from the ffmpeg-
side data alone. The libva-path WAYLAND_DEBUG comparison after iter9
is a follow-up validation that confirms the fix handles both producer
shapes, not a prerequisite for writing it.

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

phase0_findings.md

@@ -40,11 +40,9 @@ create_immed(wl_buffer#56, 1920, 1080, NV12, flags=0)
 - mpv's `vo=dmabuf-wayland` is the unique broken path because it constructs the wl_dmabuf protocol message itself, mishandling the producer's plane semantics.
 - mpv's `vo=wlshm` is fine because it goes through CPU memcpy, bypassing the dmabuf protocol entirely.
 
-**Deferred verifier (gates iter1's actual fix):**
+**iter1 is unblocked.** The wl_dmabuf message in the WAYLAND_DEBUG trace is internally inconsistent on its own — combining per-plane fds with a single-allocation offset for plane 1 is something no valid producer can claim simultaneously. mpv's translation layer produces this regardless of which producer feeds it. The fix can be written from the ffmpeg-side data alone.
 
-Re-run the WAYLAND_DEBUG capture with `--hwdec=vaapi` (libva path) once `libva-v4l2-request-fourier#1` is fixed and the cap_pool/REQBUFS cascade stops blocking libva playback. If both paths produce the same wrong `.add()` pattern → bug is purely in mpv VO. If only one does → that path's producer (libva or ffmpeg V4L2 hwaccel respectively) is the bug.
-
-This means iter1's fix work cannot start until libva-multiplanar iter9 lands. dmabuf-modifier-triage iter1 is **blocked-on**: libva-multiplanar/iter9.
+**Follow-up validation (not a prerequisite):** once `libva-v4l2-request-fourier#1` is fixed and the cap_pool/REQBUFS cascade stops blocking libva playback, re-run the WAYLAND_DEBUG capture with `--hwdec=vaapi` to confirm the same fix also handles the libva path. If both paths produce the same wrong `.add()` pattern → fix is correct. If only one does → expand the fix to handle both producer shapes (the AVDRMFrameDescriptor and VADRMPRIMESurfaceDescriptor mappings to wl_dmabuf may need separate logic).
 
 **Working ohm HW-decode workflow until fix lands:**