fix(map): complete live Cesium provider path

docs/21_MISSION_CORE_MAP_PAGE_INTEGRATION_PLAN.md

@@ -1,6 +1,7 @@
 # Mission Core Map Page + Cesium integration plan
 
-Status: proposed for product-owner acceptance, 2026-07-29
+Status: M0–M3 implemented for the local operator contour; operational
+acceptance in progress, 2026-07-29
 
 ## Objective
 
@@ -144,9 +145,9 @@ browser cache, per-application TileCache, Docker volume or a second Gateway.
 
 ### Shared renderer gate
 
-`@nodedc/page-patterns` already publishes the runtime-neutral Map Page
-definition, but the Cesium adapter is not a published package. Production reuse
-requires a shared reviewed package for:
+`@nodedc/page-patterns` publishes the runtime-neutral Map Page definition and
+`@nodedc/map-cesium-react@0.1.0` now owns the shared Cesium adapter consumed by
+Mission Core. The package boundary covers:
 
 - provider startup and independent imagery/terrain/buildings readiness;
 - Gateway-proxied Cesium resource creation;
@@ -155,16 +156,17 @@ requires a shared reviewed package for:
 - elevated target and label presentation;
 - camera and cache-intent application.
 
-Foundry and Mission Core must consume the same package revision. Copying the
-Foundry application renderer into Mission Core is rejected. Cesium remains a
-lazy chunk loaded only when the map workspace opens.
+Foundry and Mission Core must remain on the same reviewed package revision.
+Copying the Foundry application renderer into Mission Core remains rejected.
+Cesium is a lazy chunk loaded only when the map workspace opens.
 
 ## Credential and control-plane decision
 
 Mission Core does not need to receive a Cesium token to render the map. The
 existing platform token remains owned by Platform Map Gateway, and Mission Core
-uses it only after Gateway reports a configured/verified state. The current
-network check did not independently verify that state.
+uses it only after Gateway reports a configured/verified state. The connected
+local Gateway reports `ionConfigured=true` and serves the canonical assets
+without exposing credentials.
 
 The proposed `API и ключи` settings section is a write-only Platform
 control-plane client:
@@ -335,15 +337,23 @@ unbounded reconnect loops.
 
 ## Current blockers and evidence
 
-1. The Cesium adapter is not currently available through a published shared
-   package; exact code reuse is blocked until that boundary exists.
-2. Mission Core lacks authenticated admin authority, so platform token rotation
+1. The shared Cesium adapter, Mission Core BFF and real map-first workspace are
+   admitted. Browser acceptance on `127.0.0.1:8000` reports `Карта готова`;
+   imagery, terrain and 3D buildings each report `Готов`, with no blocking map
+   error.
+2. The connected Gateway is configured with assets `1`, `2` and `96188`.
+   Rendering the acceptance viewport increased the persistent live-cache count
+   from 3270 to 3282 without a browser credential or direct provider route.
+3. Mission Core lacks authenticated admin authority, so platform token rotation
    cannot be exposed safely yet.
-3. K1 currently has no admitted geodetic anchor, so live scanner targets are a
+4. K1 currently has no admitted geodetic anchor, so live scanner targets are a
    later data-contract slice.
-4. From the current Mac network, direct safe probes to the expected private
+5. From the current Mac network, direct safe probes to the expected private
    Synology Map Gateway/Platform/AMD health endpoints timed out. End-to-end
-   acceptance requires the intended LAN route; no address will be hard-coded to
+   NAS/cache-only acceptance still requires the intended LAN route. The
+   currently connected development Gateway uses a persistent local Docker
+   volume, so it proves the browser/BFF/Gateway/provider contract but not the
+   final Synology failover path. No address is hard-coded in frontend state to
    hide this condition.
 
 None of these blockers requires a new product window, Engine embedding,