multi-screen M6 for the browser: segment XR_DXR_weave rects per screen in the service, per-screen eyes out #1884

Multi-screen M6 now covers, on Windows, the in-process D3D11 / D3D12 compositors (#1857, #1878, #1879, #1880) and the service's direct single-client pipeline for IPC sessions (#1881, ADR-047 Amendment 3): a window straddling two Leia panels is woven per screen by that screen's DP, each half tracked by its own camera, with per-segment views. All three were confirmed by eye on the two-panel win rig on 2026-10-09.

The DisplayXR Browser does not go through any of those sites. It is a present-owner on the XR_DXR_weave service path (docs/specs/extensions/XR_DXR_weave.md): it binds its HWND, submits pre-weave side-by-side pixels plus window-relative rects, and composites back a woven shared texture, with eyes flowing out to it. That weave-rect site in the D3D11 service still uses the one active-display DP and the one tracked eye pair, so an inline-3D page straddling two panels is woven with the primary screen's lattice and viewer on both halves.

What it needs, reusing what #1881 put in the service:

• Split each submitted weave rect at the screen seam (the service owns the screen registry; comp_segments_compute already partitions a window rect into per-screen canvases) and weave each part with that screen's DP: the segment manager's per-screen windowless DPs (create_dp_d3d11_for_screen + set_present_origin, scissor = the part), into the same shared woven texture.
• Per-screen eyes out to the caller. The browser renders its SBS pixels from the eye pair the runtime returns; a straddling rect needs one pair per screen (the DS1's own tracker), i.e. the weave API has to return eyes per rect part (an XR_DXR_weave revision), and the browser side has to render a rect's two parts from two viewers — the same split the per-segment views make for OpenXR apps.
• Drag-snap / xrWeaveSnapWindowRectDXR against the majority screen's lattice (ADR-047 Amendment 2 logic, comp_segments_owner_*).

Until then the browser gets M6 only for the half on the system-default screen; the other half shows the known "weaves with the wrong lattice / looks around from the wrong camera" symptom. Scope it as the browser follow-up of ADR-047 (runtime side here, browser side in displayxr-browser-pvt).