Phase 0: motivation locked + mechanism captured

Operator-supplied research question 2026-05-03: "Does cutting
out the KWin compositor enable faster video display of Brave,
chromium-fourier, and Firefox — for full SW decoding, and for
libva decoding (where possible) — on PineTab2 RK3568?"

Operator-supplied mechanism 2026-05-03 (two messages):

1. "hantro emits NV12 which the GPU can't put on a
   compositeable plane. So that is the real bottleneck of
   Wayland."

   Connects directly to predecessor's Phase 1 finding
   (kwin_overlay_subsurface/phase2_source_findings.md:170-229):
   rockchip-drm overlay Plane 45 advertises no NV12 modifier;
   Primary Plane 39 supports NV12 LINEAR but is owned by KWin
   for its compositor framebuffer. Predecessor named the
   constraint but not the consequence — the consequence is
   that NV12 → RGB GL-composite is forced on Wayland-with-KWin
   regardless of which protocol path the browser uses.

2. "A X11 pipeline would route around that by giving a portion
   of screen real estate directly to the video pipeline."

   The X11 hardware-overlay path: with X11 + non-compositing
   WM, the X server can allocate Plane 39 (NV12 LINEAR) to
   the video region and Plane 45 (RGB AFBC) to the rest of
   the desktop. Hardware-blended at scanout. NO GL-composite
   anywhere — the cost the operator named as "the real
   bottleneck" is structurally avoided.

   This is the X11 hardware-overlay mechanism that historically
   made X11 desktops good at video playback (Xv → modern
   DRI3 + XPresent + Composite-redirection-disabled).
   Wayland-with-monolithic-compositor designs cannot use this
   freedom: the compositor must own the Primary plane, so the
   plane-allocation freedom required to put NV12 video on
   Plane 39 alongside RGB chrome on Plane 45 isn't available.

phase0_findings.md updated with:
- Locked research question + 12-cell experimental matrix
  (3 browsers × 2 decode paths × 2 sessions; some N/A).
- Three separable cost components the matrix tests for
  (mandatory NV12→RGB GL conversion if hardware-overlay
  doesn't engage, fallback GL-composite, per-frame compositor
  overhead independent of NV12).
- Open questions about whether browsers actually request
  hardware-overlay presentation under X11, or whether they
  always internally composite to RGB.
- Recommendation to add mpv as a reference X11-overlay
  client: distinguishes "X11 path works on this hardware"
  from "browsers actually use the X11 path."

worklist.md updated:
- Phase 0 motivation + matrix items ticked.
- Pre-Phase-1 inventory broken out: state snapshot, X11
  path inventory, browser-overlay-path inventory, mpv
  reference, X11 measurement-tool inventory, A1 Wayland
  baseline anchor.
- Phase 1 sketch: binding cells per matrix cell, clear-pass /
  clear-fail thresholds, measurement protocol mirroring the
  predecessor's phase3_protocol.md structure.

README banner updated to reflect locked motivation +
mechanism summary + matrix shape.

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

README.md

@@ -1,21 +1,31 @@
 # x11-session-research
 
-> **Status: PHASE 0 — research question pending operator
-> confirmation.** See [`phase0_findings.md`](phase0_findings.md)
-> § "Research question (provisional)" for the candidate framing
-> drafted from the predecessor campaign's close-out. Phase 1
-> lock will not happen before the operator confirms or
-> redirects.
+> **Status: PHASE 0 — motivation locked 2026-05-03.**
+> See [`phase0_findings.md`](phase0_findings.md) §
+> "Research question (LOCKED 2026-05-03)". Phase 1 still
+> requires the four pre-question Phase 0 deliverables
+> (state snapshot, X11 path inventory, browser-overlay-path
+> inventory, baseline anchor) before binding cells lock.
 
-Campaign to investigate X11 session behaviour on PineTab2
-RK3568, in the context of the just-closed
-[`kwin_overlay_subsurface`](../kwin_overlay_subsurface/)
-campaign. Whether running an X11 (Xorg) session on the same
-hardware would (a) reproduce the drop-inversion phenomenon
-that motivated the predecessor, (b) bypass it entirely, or
-(c) introduce a different set of constraints, is the most
-likely campaign question — but this is a working assumption,
-not a locked goal. See `phase0_findings.md`.
+**Research question:** Does cutting out the KWin compositor
+enable faster video display of Brave, chromium-fourier, and
+Firefox — for full SW decoding, and for libva decoding (where
+possible) — on PineTab2 RK3568?
+
+The operator-supplied mechanism: hantro decodes to NV12;
+rockchip-drm's overlay plane cannot accept NV12, so on Wayland
+KWin must own the only NV12-capable plane (Primary, Plane 39)
+for its compositor framebuffer, which forces a GL-composite
+of every NV12 video buffer. X11 + non-compositing WM can give
+the video region directly to Plane 39 (NV12 native) and put
+the rest of the desktop on Plane 45 (RGB AFBC), avoiding the
+forced GL-composite. **The campaign's load-bearing hypothesis
+is that this plane-allocation freedom translates into
+measurable browser-video speedup.**
+
+The matrix is 3 browsers × 2 decode paths × 2 sessions = 12
+cells (some N/A where libva isn't supported). See
+`phase0_findings.md` for the full table.
 
 ## Predecessor