Integrate XCUI runtime context into SceneRuntime

docs/plan/XCUI_Phase_Status_2026-04-05.md

@@ -47,11 +47,12 @@ Current gap:
 - Engine-side runtime ownership is no longer zero: `UIScreenPlayer`, `UIDocumentScreenHost`, and `UISystem` now define a shared runtime contract for loading a screen document, ticking it with input, and collecting `UI::UIDrawData`.
 - `UISystem` now supports layered screen composition semantics: stacked screen players, top-interactive input routing, and modal layers that block lower screens.
 - `UIScreenStackController::ReplaceTop` now preserves the previous top screen if the replacement screen fails to load, so runtime menu flows do not silently drop their active layer on bad assets.
+- `SceneRuntime` now owns a dedicated `UISceneRuntimeContext`, so game/runtime code has a first-class place to configure viewport/focus, queue `UIInputEvent`s, drive `UISystem` each `Update`, and inspect the latest UI frame result.
 - Runtime screen emission now also carries concrete button text in the shared document host path instead of silently dropping button labels.
 
 Current gap:
 
-- No production game-loop integration has been wired yet from scene/runtime systems into `UISystem`.
+- Runtime UI is now wired into `SceneRuntime`, but render submission is still limited to producing `UIDrawData`; there is no game-view/runtime presenter path that automatically draws those frames yet.
 - The runtime widget library is still shallow and missing the editor-grade controls that will later be shared downward.
 
 ### 3. Editor Layer
@@ -88,6 +89,7 @@ Current gap:
 - `new_editor_xcui_hosted_preview_presenter_tests`: `12/12`
 - `XCNewEditor` Debug target builds successfully
 - `core_ui_tests`: `28/28`
+- `scene_tests`: `65/65`
 - `core_ui_style_tests`: `5/5`
 - `ui_resource_tests`: `11/11`
 - `editor_tests` targeted bridge smoke: `3/3`
@@ -119,11 +121,21 @@ Current gap:
 - Engine runtime layer added:
   - `UIScreenPlayer`
   - `UIDocumentScreenHost`
+  - `UISceneRuntimeContext`
   - `UIScreenStackController`
   - `UISystem`
   - layered screen composition and modal blocking semantics
 - Runtime/game integration scaffolding now includes reusable `HUD/menu/modal` stack helpers on top of `UISystem`.
 - `UIScreenStackController` replacement now rolls back safely on failure instead of popping the active top layer first.
+- `SceneRuntime` now exposes XCUI runtime ownership directly:
+  - `GetUISystem()`
+  - `GetUIScreenStackController()`
+  - `GetLastUIFrame()`
+  - `SetUIViewportRect(...)`
+  - `SetUIFocused(...)`
+  - `QueueUIInputEvent(...)`
+  - `ClearQueuedUIInputEvents()`
+  - automatic `UISystem` ticking during `SceneRuntime::Update(...)`
 - Runtime document-host draw emission now preserves button labels for shared screen rendering.
 - RHI image path improvements:
   - clipped image UV adjustment
@@ -162,7 +174,7 @@ Current gap:
 
 ## Next Phase
 
-1. Expand runtime/game-layer ownership from the current document host + layered `UISystem` into reusable menu/HUD stack patterns and engine runtime integration.
+1. Expand runtime/game-layer ownership from the current `SceneRuntime` UI context into scene-declared HUD/menu bootstrapping, draw submission, and higher-level runtime UI policies.
 2. Promote the current editor-facing widget prototypes out of authored `LayoutLab` content and into reusable XCUI widget/runtime modules, then continue with toolbar/menu and more native shell-owned chrome.
 3. Add a native XCUI host compositor on the existing window-level compositor seam so `new_editor` can present without going through ImGui-owned draw data.
 4. Reduce remaining ImGui leakage in hosted preview surfaces and panel contracts now that the compositor seam is in place.