README: known issues at iter8 production tip — cap_pool cascade + dmabuf-wayland green

Two bugs uncovered in fresh-install interactive mpv testing on ohm
2026-05-08, immediately after the libva-v4l2-request-fourier-1.0.0.r280.65969da-1
package landed on [marfrit]:

1. libva cap_pool / REQBUFS / iter6-REINIT lifecycle cascade — filed
   marfrit/libva-v4l2-request-fourier#1. Probe-context + decode-context
   cap_pool double-init, EBUSY on REQBUFS (no STREAMOFF between),
   iter6 REINIT bad-fd, OUTPUT queue ENOMEM. Phase-5-sonnet-C4 from
   iter5 was prescient about this race.

2. dmabuf-wayland↔KWin presentation handoff produces solid green —
   independent of libva (also reproduces with ffmpeg's V4L2 request
   hwaccel). vo=gpu shows correct picture, so decoder is fine.
   Likely modifier/pitch handshake regression between iter5 close
   2026-05-05 and now. Not yet filed; needs separate triage.

Iter5/8 close claims of "mpv --hwdec=vaapi smooth" do not hold against
fresh-install + fresh-Plasma-session interactive testing. The working
HW-decode workflow on ohm right now is:

  mpv --hwdec=v4l2request --vo=gpu fourier-test/...

Both issues must be triaged before any future iteration claims a
clean ohm path.

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

README.md

@@ -52,6 +52,22 @@ Per the [`feedback_replicate_baseline_first.md`](../../.claude/projects/-home-mf
 | 4 | Closed 2026-05-05 | "Track A solo — fix the iter1+2+3 carryover frame-11 EINVAL." | GREEN. Three correctness fixes landed (DPB `fields=FRAME_REF` + skip stale entries, fresh `request_fd` per frame, B-slice L1 reflist `.fields` copy-paste). mpv direct stress test verified 2130 BeginPictures over 90s with 0 EINVAL events of any kind — real-time HW decode through libva-v4l2-request-fourier. See `phase8_iteration4_close.md`. |
 | 5 | Closed 2026-05-05 | "A+G+B+E quad: DEBUG sweep + PGO-disabled Firefox rebuild + libplacebo segfault + multi-context safety." | GREEN, all four tracks. ~339 lines of instrumentation removed (iter1+iter3+iter4 noise) — driver builds clean, per-frame log noise zero. firefox-fourier 150.0.1-1.1 rebuilt non-PGO (169 MB libxul, 21× smaller, 2.7× faster decode). LAST_OUTPUT_* moved per-driver-data. mpv `--vo=gpu` 0 segfaults. One iter6+ caveat: cap_pool resolution-change race latent under untested consumer probe patterns (Phase 5 sonnet C4). See `phase8_iteration5_close.md`. |
 
+## Known issues at iter8 production tip (2026-05-08)
+
+The iter8 close (`65969da3`) was packaged as `libva-v4l2-request-fourier-1.0.0.r280.65969da-1` and shipped to `[marfrit]` on 2026-05-08. Interactive testing on ohm immediately after the rollout exposed two campaign-relevant bugs neither iter5 nor iter8 caught. **Both must be triaged before any future iteration claims a clean ohm path.**
+
+1. **libva cap_pool / REQBUFS / iter6-REINIT lifecycle cascade** — filed at [marfrit/libva-v4l2-request-fourier#1](https://git.reauktion.de/marfrit/libva-v4l2-request-fourier/issues/1). Under `mpv --hwdec=vaapi` interactive playback, `cap_pool_init` runs twice for slots 0..23 (probe-context + decode-context, no teardown between), `VIDIOC_REQBUFS` returns EBUSY (queue still STREAMON'd), iter6's per-OUTPUT-slot REINIT (commit `a09c03c`) chokes on a Bad fd, OUTPUT queue (`type=9`) hits ENOMEM after a few REQBUFS retries, decode aborts with `Failed to create surface: 2 (resource allocation failed)`. The Phase-5-sonnet-C4 caveat from iter5 (`cap_pool resolution-change race latent under untested consumer probe patterns`) was prescient — this is exactly that race, made hard-failing by iter6/7's additions. iter9 input.
+
+2. **dmabuf-wayland↔KWin presentation handoff produces solid green** — independent of libva. `mpv --hwdec=v4l2request --vo=dmabuf-wayland` (libva-bypassed, ffmpeg's native V4L2 hwaccel) **also** produces solid green frames on ohm/KWin 6. `mpv --hwdec=v4l2request --vo=gpu` displays the correct picture (slow, GPU shader path on Mali-G52). So the green is dmabuf-wayland-specific, not decoder-side. KWin's `linux-dmabuf-v1` advertised list contains only `NV12 LINEAR (modifier 0x0)` — likely an NV12 modifier/pitch handshake regression somewhere between iter5 close (2026-05-05, "mpv `--hwdec=vaapi` smooth") and now. Could be on the libva side (vaExportSurfaceHandle modifier reporting), the ffmpeg side (drm_prime export modifier), or KWin/Mesa-panfrost upgrade since 2026-05-05. Not yet filed — needs separate triage.
+
+**Working ohm HW-decode path right now (workaround):**
+
+```bash
+mpv --hwdec=v4l2request --vo=gpu fourier-test/bbb_1080p30_h264.mp4
+```
+
+— bypasses both bugs (libva replaced by ffmpeg V4L2 request hwaccel; dmabuf-wayland replaced by GPU shader path). Slow but correct. The user-facing claim "mpv `--hwdec=vaapi` smooth" from iter5/8 closes does **not** hold against fresh-install + fresh-Plasma-session interactive testing, which is the production-tip user surface.
+
 ## Predecessor work that this campaign builds on
 
 State (carry-over) — fork content, file:line pointers, contract analyses: