Add libva-v4l2-request-ohm-gl-fix package

Mirrors phase6/step1/ from the ohm_gl_fix campaign. Contract-correct
hantro multi-planar / chromium-149-era stateless H.264 port of
bootlin's libva-v4l2-request, patches 0001..0018 + fourier-local.

Honest characterisation in README:
  - Builds cleanly on chromium-builder LXC (boltzmann)
  - vainfo enumerates H.264 profiles cleanly with LIBVA_DRIVER_NAME=v4l2_request
  - NOT on Brave's decode path on ohm_gl_fix stack — Brave uses
    Chromium's own V4L2VideoDecoder in media/gpu/v4l2/.
  - Most likely useful for a future Firefox-via-libavcodec-vaapi
    campaign, modulo a separate Mesa-panfrost WSI pitch issue.
  - DEBUG patches (0010, 0011, 0014) intentionally kept in series
    for development; remove for cleaner production runs.

Audit trail in the source repo at ohm_gl_fix:
  phase6/step1/audit_0008_decode_params_2026-05-01.md
  phase6/step1/api_contract_findings_2026-05-01.md
  phase3_remeasure_2026-05-02/B3_decoder_discovery.md (why this
    isn't on Brave's path)

arch/libva-v4l2-request-ohm-gl-fix/README.md

@@ -0,0 +1,58 @@
+# libva-v4l2-request-ohm-gl-fix
+
+Bootlin's libva-v4l2-request VA-API backend, with hantro-vpu
+multi-planar + chromium-149-era stateless H.264 patches developed
+in the [ohm_gl_fix campaign](../../../ohm_gl_fix/) Phase 6 Step 1
+(2026-05-01..2026-05-02).
+
+Patches 0001-0018 are contract-correct against the kernel V4L2
+stateless H.264 UAPI, validated by inspection against
+hantro_h264.c and v4l2_h264_init_reflist_builder() in linux 6.19.x.
+See ohm_gl_fix's `phase6/step1/audit_0008_decode_params_2026-05-01.md`
+and `phase6/step1/api_contract_findings_2026-05-01.md` for the
+audit trail.
+
+## Honest characterisation
+
+This package compiles cleanly, installs cleanly, and `vainfo` with
+`LIBVA_DRIVER_NAME=v4l2_request LIBVA_V4L2_REQUEST_VIDEO_PATH=/dev/video1`
+enumerates all H.264 profiles. It is, however, **not on Brave's
+critical decode path** on the ohm_gl_fix Step-1+Step-2 stack —
+Brave/Chromium uses its own `V4L2VideoDecoder` in
+`media/gpu/v4l2/`, opens `/dev/video1` directly, and never loads
+libva. See `phase3_remeasure_2026-05-02/B3_decoder_discovery.md`
+in the ohm_gl_fix repo for the strace/maps evidence.
+
+For libva consumers that DO route through libva (mpv with
+`--hwdec=vaapi`, ffmpeg-vaapi, Firefox with
+`media.ffmpeg.vaapi.enabled=true`), this backend would in
+principle engage hantro hardware decode — but each consumer hits
+its own downstream issue:
+
+- mpv `--vo=gpu-next`: blocked by a Mesa-panfrost WSI pitch bug
+  during EGL dmabuf import (out of scope for this package; see
+  `phase3_remeasure_2026-05-02/A3_mesa_wsi_pitch.md`).
+- mpv `--vo=image`: silently falls back to libavcodec SW decode
+  rather than engaging the libva session (see
+  `phase3_remeasure_2026-05-02/A1_morning_pass_disambiguation.md`).
+  Reason not yet diagnosed.
+
+The most likely use case where this backend cleanly delivers
+hardware decode end-to-end is **Firefox via libavcodec-vaapi**, on
+a stack that also has the Mesa pitch issue resolved (or that
+doesn't hit the EGL import path because Firefox's video element
+composites differently). Untested at time of writing.
+
+## DEBUG patches in the series
+
+`0010-DEBUG-hex-dump-output-capture.patch`,
+`0011-DEBUG-sentinel-capture-buffer.patch`, and
+`0014-DEBUG-vapic-bytes-dump.patch` produce verbose stderr output
+useful for diagnosing decode-path issues but excessive for
+production. They are intentionally kept in the applied series
+during development; remove for cleaner runs.
+
+## Status
+
+Tagged stable as of 2026-05-02 against chromium-149 / linux-6.19.10
+/ libva-2.22.0. Contract-correct; ecosystem-validation-pending.