Add shared ConfigKit loading and runtime settings conversion

docs/internal/sources.md

@@ -34,6 +34,15 @@ mutating the document or exposing rejected values. Application path values keep
 working-directory-relative meaning. ConfigKit owns strict YAML decoding and
 presence semantics, including dynamic integer values in backend parameters.
 
+The new `Load` boundary selects an explicit file, the first existing implicit
+configuration file, or ConfigKit's defaults-only source. Only absence advances
+implicit discovery. One ConfigKit load applies explicit application overrides
+before validation and returns a result containing the resolved document and
+its frozen inspection records. `Settings` converts that document into the
+existing runtime settings with backend IDs sorted; it does not read files or
+apply another merge. Imports and selected overlays remain disabled until their
+own user-facing integration is ready.
+
 The executable commands still use the existing loader. The new definition is
 internal preparation and is not yet an alternative user-selectable configuration
 mode or a change to the current [configuration contract](../config.md).

docs/roadmap/implementation.md

@@ -147,7 +147,9 @@ policy. Existing executable behavior still passes its tests.
 
 ## Stage 2: Build Discovery And The Shared Loading Boundary
 
-**Status: Not started.**
+**Status: Complete.** Ordered source discovery, one ConfigKit load, typed
+diagnostics, and settings conversion are covered by focused file/default and
+override tests. Existing commands still use the old entry point until cutover.
 
 Primary files: `internal/config` and its tests; `docs/internal/sources.md`.