Bring the host up to the current XR_DXR_weave spec (v6 N-view atlas, v3 batch, legacy fallback)

[dfattal]

Brings the host up to date with the current XR_DXR_weave spec, and verifies it
on real hardware rather than in theory.

What was wrong

• Vendored XR_DXR_weave.h was SPEC_VERSION 1; the runtime's canonical copy is
  6. The host submitted through the pre-v3 single-rect call — still supported,
  so it worked, but as the standalone integration example it taught an API five
  versions stale.
• displayxr-common pinned v2.5.0; latest is v2.6.1.
• CI was lint-only, so "does it build against a current runtime" had been
  unverified since July.

What this does

1. Headers re-synced byte-for-byte from displayxr-runtime's
src/external/openxr_includes/openxr/ (the canonical copy), which also picks up
XR_DXR_wayland_surface_binding.h and the corrected 1004999xxx registry.
displayxr-common → v2.6.1.

2. Modern submit paths, negotiated down from the spec version the runtime
reports (never the vendored header's):

Runtime spec	Path
≥ 6 (preferred)	XrWeaveSubmitLayoutDXR N-view worst-case atlas
3 – 5	XrWeaveSubmitRectsDXR batch, firstChunk on ≥ 5
< 3	legacy per-element — documented fallback, logic unchanged

The batch shape follows displayxr-browser patch 0027 (SubmitBatchWin), including
the 32-rect chunking.

On v4/v5/v6 — what I included and why. v6 is the primary path: it makes the host
an ordinary N-view client (ADR-010 worst-case atlas + ADR-030 crop-before-DP), packing
the atlas itself at the active mode's viewScale, sized from the display so window
resize never reallocates. Crucially it owns the alpha between elements, so the woven
output draws back whole-window in one premultiplied "over" blit with no dependence on a
runtime-side clear. v5 firstChunk is used on the v3 rung, where that clear is what
makes the same whole-window draw-back safe.

v4 overlays are deliberately out: this demo paints no crisp 2D over the woven 3D —
the page's 2D surround sits around and under the elements, which the page base already
handles. Adopting v4 would mean inventing a second window-sized premultiplied-RGBA atlas
producer and a stacking-order rasteriser existing only to exercise the field. v6 beyond
viewCount == 2 is also out: filling a 4-view mode needs the page to render 4 views,
which is a demo-page rewrite, not a host change.

3. A pre-existing geometry bug, fixed. Element rects were clamped to the page, so
an element scrolled off the top (negative y) collapsed into a full-height rect pinned at
y=0 — the host then fed page text to the weave and drew woven text back over the
page. That is the ragged-canvas-while-scrolling artifact, and it reproduces on main
(I rebuilt unmodified main to confirm before touching it). Rects are now intersected
with the page and dropped when empty: an off-screen element is not a weave region.

4. DXR_WEAVE_MAX_SPEC=<n> caps the negotiated version (never raises it), so one build
reproduces every submit shape the extension has shipped against a current runtime — the
knob for bisecting "is this bug batch-only?", which is half of why this repo exists.

5. CI: a cached windows-latest build that asserts the exe lands, plus a non-blocking
header-sync job diffing the vendored headers against displayxr-runtime@main — it would
have caught this five-version gap. Also neutralizes one vendor company name in the README
that predates this branch (never caught because lint.yml only runs on pull_request).

Verified on hardware

Real 3D display, vendor DP (not sim_display), non-elevated via explorer.exe against the
non-elevated service:

Runtime	v2.5.0-3-g7262f3bc1, reports XR_DXR_weave spec v6
Display processor	vendor plug-in v2.0.7, plug-in ABI v5
Active mode	2 views, 2×1 grid, viewScale 0.5 × 0.5 → worst-case atlas 3840×2160
CEF	149.0.4 (Chromium 149.0.7827.156)

• v6 path: one submit/frame, 3 elements, ~1.4 ms round-trip, zero errors; correct at
  rest and under scroll, confirmed on the live display.
• v3 batch + v5 firstChunk (via DXR_WEAVE_MAX_SPEC): ~1.26 ms/frame.
• Legacy per-element: ~2.6 ms/frame, same 3 elements — the per-call fixed cost
  (IPC round-trip + shared-texture open + keyed-mutex + fence) is what batching amortizes.

The DP is genuinely weaving, not passing through: sampling a scanline across a cube edge in
the composited output alternates column-by-column between background 13,18,23 and cube
93,30,23 — the interlace comb. Flat regions inside the same element show zero
column-to-column delta.

🤖 Generated with Claude Code

https://claude.ai/code/session_01LW3wiw5Ds4Tj8AaGUQAFqF