Android: window-origin contract — DP slot set_window_screen_rect + Choreographer poll of getLocationOnScreen

[dfattal]

Part of #1031 · ADR-036 D6. Common to Architecture A and C.

A compositor instance weaves into its own window, so it needs that window's on-panel origin
every frame. Android's trap (report F9): a pure window move raises no resize — only a
oneway IWindow.moved — and SurfaceFlinger repositions the layer with the old buffer, so the
interlace phase goes stale for the whole drag.

Runtime:

• New append-only DP vtable slot set_window_screen_rect(x, y, w, h, display_id) under ADR-020
  (struct_size negotiation; old plug-ins unaffected).
• Client side: sample View.getLocationOnScreen() from a Choreographer callback. Opt out of
  view-bounds sandboxing — OEM OVERRIDE_SANDBOX_VIEW_BOUNDS_APIS makes that call
  window-relative; set PROPERTY_COMPAT_ALLOW_SANDBOXING_VIEW_BOUNDS_APIS=false.
• Architecture A: call the compositor directly. Architecture C: forward over the existing
  window-metrics IPC channel (multi_compositor_get_window_metrics,
  comp_multi_compositor.c:2076-2090).

Vendor mapping is a separate issue: DisplayXR/displayxr-leia-plugin#150.
ADR-033 is unchanged — this reports geometry; the weaver still owns phase.

[dfattal]

Eyeball-confirmed on NP02J (2026-08-18): two freeform windows (A 0,60 1280x1540, B 1280,60 1280x1540), both weave correctly at their own window origin — right-window phase offset gone, brightness equal. Chain verified end to end (windowRect → updateWindowRect → WINDOW_RECT: session window → weave full-target screen-pos); pure move propagates app→weave in ~9 ms. Branch feat/1033-window-origin @ 4757823 (rebased on the PoC stack incl. #1040/#1041) + leia-plugin feat/150-set-window-screen-rect. PR next.