fix: engine_render_gated in built manifests (#322) + WSUI panel aspect from the workspace tile (#323)

[dfattal]

Two independent shell-mode fixes, one commit each. Both were observed on the live panel on 2026-09-13 against plug-in v2.19.1, runtime v2.16.31, shell 2.2.0.

#322 — every dev build launched by the shell rendered a black tile

The shell launches a 3D app SW_HIDE unless the app's manifest declares that its engine gates rendering on a shown window. Unity does gate on it, so a hidden player submits black eye slices while the provider's own trace looks perfect. Only the displayxr-unity-samples NSIS installer added the key by hand, which is why an installed sample worked and a fresh build of the same scene did not.

BuildManifestJson serves both bodies — the sidecar next to the exe (CLI launch path) and the registered manifest under %LOCALAPPDATA% (launcher path) — so the flag is emitted there, immediately after "type", unconditionally. The processor only ever writes manifests for Unity players, and the key is harmless on the launcher path. No other field, value or ordering changes.

Changed: Editor/DisplayXRBuildProcessor.cs (one field), CHANGELOG.md.

#323 — WindowSpaceUI overlay stretched with the workspace tile

Under the shell Unity's main window is launched minimized and never follows the tile, so Screen.width/height stay frozen at the launch size. The eye swapchain does follow the tile (the provider re-polls the tile canvas every reconcile), but TryGetPanelPixelSize read Screen.*, so the overlay RT was never re-created and the runtime's stretch into the fractional panel rect stopped being the identity — a narrow tile squeezed the UI horizontally.

• New export displayxr_get_render_canvas_size(w, h): returns 1 plus the live workspace-tile canvas when dxr_prov_workspace_tile_size has one, 0 otherwise. It lives in displayxr_native_shared.cpp, which every platform compiles, and reads only the provider's cached pixel counts — no Win32 geometry call, so nothing crosses a DPI space, and no new platform ifdef. On macOS and Linux the tile size is never polled, so it returns 0 and behaviour there is byte-identical.
• C# prefers it when shell mode is on and it answers non-zero, and falls back to Screen.* otherwise. The existing kResizeSettleSeconds debounce then absorbs tile drag-resizes exactly as it absorbs window resizes today.
• One log line, emitted only when the source switches (TryGetPanelPixelSize runs twice a frame, so this must never be per-frame): "[DisplayXR] wsui: panel size source = workspace tile (777x875)".
• Shell mode and a missing entry point are both latched, so the steady state adds no per-frame P/Invoke.

Changed: native~/displayxr_native_shared.cpp, native~/displayxr_exports.h, Runtime/DisplayXRNative.cs, Runtime/DisplayXRWindowSpaceUI.cs, the rebuilt Windows DLL, CHANGELOG.md.

Verification

• native~\build-win.bat succeeded, no new warnings. Runtime/Plugins/Windows/x64/displayxr_unity.dll — SHA256 a48552cef0a89765a3cfc1e3521399e8812725d3953304649ac2afa297322a45, 207,872 bytes; the new export string is present in the image.
• Both samples/urp-singlepass-ui and samples/birp-multipass were rebuilt from displayxr-unity-samples against this working tree (local file: override, not committed there). Both players' sidecars now carry "engine_render_gated": true, and both players ship this exact DLL.
• Hardware verification of the two visual symptoms (black tile, squeezed overlay) is with the author on the Leia SR panel; do not merge before that lands.

Fixes #322
Fixes #323

🤖 Generated with Claude Code

https://claude.ai/code/session_012co2j1fdmZ2AdEAp4Y3xpp