lock iter1 acceptance criterion: before/after screenshot anchor

Operator decision 2026-05-08: the iter1 fix is shipped only when frame
10 of the bbb fixture under --vo=dmabuf-wayland matches the expected
reference (captured via --vo=gpu on same hardware/session).

- screenshots/frame10_dmabuf_green.png — current broken state
- screenshots/frame10_expected.png — target post-fix state
- screenshots/README.md — verification protocol (SSIM > 0.95 + valid
  WAYLAND_DEBUG .add() semantics + no regression on vo=gpu / vo=wlshm)
- phase0_findings.md — references the criterion in the conclusion section

This locks the campaign's deliverable. Patches that change wire-protocol
.add() shape but don't restore the picture do not satisfy iter1.

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

screenshots/README.md

@@ -1,11 +1,27 @@
-# Screenshots
+# Screenshots — iter1 acceptance criterion anchor
 
-Reference captures of the user-visible bug. Filed alongside `phase0_findings.md` so future readers see the symptom directly without reproducing it.
+These two screenshots are the **locked acceptance criterion** for the iter1 fix per operator decision 2026-05-08. The fix in `mpv vo_dmabuf_wayland.c` (or wherever the plane-semantics mismatch turns out to live) is considered shipped only when frame 10 of the bbb fixture under `--vo=dmabuf-wayland` matches the expected reference.
 
-## frame10_dmabuf_green.png
+## Before fix (current broken state) — `frame10_dmabuf_green.png`
 
 `mpv --hwdec=v4l2request --vo=dmabuf-wayland --pause --start=00:00:00.42 --fullscreen fourier-test/bbb_1080p30_h264.mp4` on ohm, frame ~10 of `bbb_1080p30_h264.mp4` (24 fps), captured via `spectacle -b -f -n` 2026-05-08.
 
-Shows uniform dark green fill where the bbb test pattern should be. Black bars top/bottom are letterboxing from fullscreen presentation on PineTab2's 1280×800 display vs the 1920×1080 / 16:9 source — they're not part of the bug.
+Uniform dark green fill ≈ RGB(0, 75, 0). Matches the predicted output of an all-zero NV12 buffer (Y=0, U=0, V=0) through BT.601/709 → RGB conversion. Confirms the [marfrit/dmabuf-modifier-triage#1](https://git.reauktion.de/marfrit/dmabuf-modifier-triage/issues/1) diagnosis: KWin reads UV plane past-EOF on its `fd 42`, gets zeros, renders dark green.
 
-The dark green color is approximately RGB(0, 75, 0), which matches the predicted output of an all-zero NV12 buffer (Y=0, U=0, V=0) through BT.601/709 → RGB conversion. Confirms the [marfrit/dmabuf-modifier-triage#1](https://git.reauktion.de/marfrit/dmabuf-modifier-triage/issues/1) diagnosis: KWin reads UV plane past-EOF on its `fd 42`, gets zeros, renders dark green.
+Black bars top/bottom are letterboxing (PineTab2 1280×800 display vs 1920×1080/16:9 source) — not part of the bug.
+
+## After fix (expected target) — `frame10_expected.png`
+
+Same command but `--vo=gpu` (the working VO that bypasses the wl_dmabuf protocol path). Same frame, same fixture, same display.
+
+Bbb's intro fades in from black, so frame 10 of the source is genuinely dark — the dim grass/silhouette on the right edge is real content. (For a more visually distinct anchor, frame 100+ would show the butterfly scene; frame 10 stays per operator spec.)
+
+## Verification protocol
+
+The iter1 fix has shipped when:
+
+1. With the fix applied, running the `--vo=dmabuf-wayland` reproduction command at frame 10 produces a screenshot that **structurally matches** `frame10_expected.png`. Pixel-level identity is not required (compositor scaling / ditherering may differ); structural similarity (SSIM > 0.95 for the central frame area, ignoring letterbox bars) is the threshold.
+2. The `WAYLAND_DEBUG=1` capture of the same run shows the `.add()` calls in either of the two valid forms documented in [marfrit/dmabuf-modifier-triage#1](https://git.reauktion.de/marfrit/dmabuf-modifier-triage/issues/1):
+   - same fd repeated for both planes with non-zero offset for plane 1 (single-allocation form), or
+   - different fds for each plane with offset=0 for both (per-plane form)
+3. The fix doesn't regress the `--vo=gpu` working path or `--vo=wlshm` working path on the same fixture.