Split utility window contracts from feature factories

docs/plan/editor-core-refactor-plan.md

@@ -33,12 +33,12 @@ The reusable layer is mostly healthy:
 - `editor/include/XCEditor/**` and `editor/src/**` form `XCUIEditor`.
 - `XCUIEditor` is testable and mostly free of app, Win32, and D3D12 concerns.
 
-The app layer has a good directory vocabulary but weak enforcement:
+The app layer has a good directory vocabulary but enforcement is still
+incomplete:
 
-- `editor/app/Composition` directly includes concrete feature-panel contracts
-  from `editor/app/Features`.
-- `editor/app/Features` also includes `Composition/EditorContext.h` and
-  `Composition/EditorPanelIds.h`, creating a composition/feature cycle.
+- `XCEditorCore` exists, but its include surface still exposes the whole
+  `editor/app` root to app code.
+- Some feature panels still use `Composition/EditorContext.h` directly.
 - Win32 and D3D12 currently know about each other through concrete headers.
 - App-side tests exist but are not consistently wired into CMake; some are
   stale and reference removed headers.
@@ -48,6 +48,14 @@ Completed boundary cuts:
 - Project service ownership has moved to `editor/app/Services/Project`.
   `EditorProjectRuntime` depends on the service-owned `ProjectBrowserModel`,
   and `Features/Project/ProjectPanel` owns the widget-tree projection.
+- Panel IDs live under `editor/app/Core/Panels`, and workspace panel runtime
+  contracts live under `editor/app/Core/WorkspacePanels`.
+- Shared window category, lifecycle, chrome-policy, and native-host-policy
+  contracts live under `editor/app/Core/Windowing`.
+- Utility-window kinds, descriptors, and panel contracts live under
+  `editor/app/Core/UtilityWindows`; concrete Color Picker/Add Component panel
+  creation lives under `editor/app/Features/EditorUtilityWindowRegistry.*` and
+  is injected from `Application`.
 
 The root issue is not the existence of a single executable target by itself.
 The root issue is that shared app contracts are stored inside concrete layer
@@ -65,6 +73,7 @@ editor/app/
     Panels/
     State/
     UtilityWindows/
+    Windowing/
     WorkspacePanels/
 
   Services/
@@ -213,7 +222,8 @@ Initial contents:
 - `app/Project/**` or `app/Services/Project/**`
 - `app/Scene/**` or `app/Services/Scene/**`
 - `app/State/**`
-- `app/UtilityWindows/**`
+- `app/Core/UtilityWindows/**`
+- `app/Core/Windowing/**`
 - `app/Windowing/**` core files that do not require Win32 or D3D12
 - host-facing abstract interfaces
 
@@ -298,9 +308,30 @@ scene services, but scene services should not depend on concrete feature UI.
 
 ### Utility Windows
 
-Move utility descriptors and kinds to `Core/UtilityWindows` if they are shared
-by windowing and features. Concrete utility panel creation remains in
-`Features`.
+Completed:
+
+```text
+UtilityWindows/EditorUtilityWindowKind.h
+UtilityWindows/EditorUtilityWindowPanel.h
+UtilityWindows/EditorUtilityWindowRegistry.*
+    -> Core/UtilityWindows/EditorUtilityWindowRuntime.h
+    -> Core/UtilityWindows/EditorUtilityWindowRegistry.*
+    -> Features/EditorUtilityWindowRegistry.*
+```
+
+Current shape:
+
+```text
+Core/UtilityWindows/EditorUtilityWindowRuntime.h
+Core/UtilityWindows/EditorUtilityWindowRegistry.*
+Features/EditorUtilityWindowRegistry.*
+```
+
+Keep utility kinds, descriptors, host context, panel contract, and factory
+type in `Core/UtilityWindows`. Keep concrete utility panel construction in
+`Features/EditorUtilityWindowRegistry.*` and inject it from the application
+composition root. Windowing may resolve descriptors from Core, but must not
+include Color Picker, Add Component, or other concrete feature-panel headers.
 
 ## Phase 5: Host Boundary Cleanup