Close remaining static atlas and export work

docs/control-loop-atlas/runtime-roots-camera-and-support-families.md

@@ -46,9 +46,16 @@
   paired wrappers
   `0x004423a0/0x004423d0` bracket that same band while also servicing the live TrackLay.win and
   StationPlace.win tool objects through `0x0050e070`, `0x00507a50`, `0x0050a530`, and
-  `0x0050e1e0`. The live `.smp` serializer uses the higher pair, while `world_entry_transition_and_runtime_bringup`
-  `0x00443a50` and `world_load_saved_runtime_state_bundle` `0x00446d40` also use the raw
-  push/pop pair directly around their heavier bundle and status spans.
+  `0x0050e1e0`. The live `.smp` serializer uses the higher pair, while the neighboring world-entry
+  branch `0x00443a50` and non-`.smp` package-save tail under `shell_map_file_world_bundle_coordinator`
+  `0x00445de0` now show the raw split explicitly. `0x00443a50` calls `0x004422d0` at `0x444e2c`,
+  services TrackLay.win and StationPlace.win entry-side helpers through `0x444e3b/0x444e4a`, then
+  later calls `0x00442330` at `0x444ecb` and services the recurring tool frames through
+  `0x444eda/0x444ee9`. The package-save tail similarly calls `0x00442330` directly at `0x00445a55`
+  and then services StationPlace.win and TrackLay.win at `0x00445a64/0x00445a73` without
+  re-entering `0x004423d0`. So the save/load-side tool choreography is no longer one uniform wrapper
+  path across world-entry, package-save, and `.smp` branches, and current local evidence does not
+  show `0x00446d40` itself directly re-entering either the raw pair or the higher wrapper pair.
   `world_region_border_overlay_rebuild` `0x004882e0`. The transport/pricing side is tighter now
   too: `0x0044fb70` first routes one null-build path through the preview ensure wrapper
   `0x0044faf0`, whose deeper worker `0x0044f840` allocates a default target through
@@ -1785,7 +1792,9 @@ The controller window dispatcher now looks like the first grounded input
   cursor drag, overlay hotspots, held Shift state, direct keyboard turn/pan/zoom bindings, the
   TrackLay and StationPlace world-command surfaces, and at least one frame-owned hover or
   focus-target branch all converge under the same shell-fed world-mode input path rather than a
-  separate gameplay-input stack.
+  separate gameplay-input stack. The ownership seam is therefore closed at the current local level:
+  the unresolved pieces are the exact per-tool or per-mode actions beneath that path, not whether a
+  later non-cursor gameplay branch bypasses the shell controller input roots.
 ### Evidence
 
 Function-map rows for `shell_controller_window_message_dispatch`,
@@ -1918,7 +1927,7 @@ Function-map rows for `shell_controller_window_message_dispatch`,
   failure strings 3083 3084 3837 and 3900, the binding-registry lookup path at `0x0045f370`, the
   registration block at `0x00460769` through `0x004608e7`, and the localized labels in
   `Data/Language/RT3.lng` ids `3466` through `3473`.
-### Open Questions
+### Current Boundary
 
 Current evidence grounds the shell-controller-backed input and frame path as the
   only coordinator after world entry; no separate outer gameplay loop or gameplay-only input
@@ -2122,12 +2131,10 @@ Current evidence grounds the shell-controller-backed input and frame path as the
   releases the cached roots `0x006d19d8..0x006d19ec`, frees the per-company cached stock-data
   handles in `0x006d1748`, invalidates controls `0x3b60` and `0x3e4e`, clears singleton
   `0x006d19f0`, and then tails into the common shell-object teardown. The
-  remaining adjacent detail-panel gates are now at least structurally bounded too even though their
-  target families are still unnamed: `0x00434db0` layers extra scenario toggle `[0x006cec78+0x4a7f]`
-  on top of the broader company-list/detail gate before allowing mode `0x0b`, while `0x00434e20`
-  only hard-blocks mode `0x06` when all three toggles `[+0x4ab3/+0x4ab7/+0x4abf]` are set and
-  otherwise, outside editor-map mode, still requires a selected-company id before the direct
-  openers `0x00440530` and `0x00440690` hand those modes to `shell_detail_panel_transition_manager`.
+  remaining adjacent detail-panel gates are now bounded tightly enough to carry by family:
+  `0x00434db0` is the scenario-toggle-gated company-detail mode-`0x0b` availability gate, while
+  `0x00434e20` is the selected-company-or-editor detail mode-`0x06` availability gate that only
+  hard-blocks when all three scenario toggles `[+0x4ab3/+0x4ab7/+0x4abf]` are set.
   The
   train-buy family is no longer just an unnamed probe pair either: the opener path is now grounded
   under the same shell-owned cadence through `shell_can_open_trainbuy_window_or_warn` and
@@ -3089,8 +3096,8 @@ The low helper strip beneath that shared family is tighter now too: `0x0052ecd0`
   when live and clear the field, but `0x004743d0` tails into the smaller base cleanup
   `0x00455650`, while `0x00474400` tails into the heavier dynamic-payload cleanup `0x00455d20`.
   The small predicate `0x00474430` simply returns `1` unless shell mode gate `0x004338c0` is
-  active, in which case it returns byte `[this+0x42]`; the exact meaning of that flag byte is still
-  open, but the mode-gated query itself is bounded now. One level higher, `0x00474450` constructs
+  active, in which case it returns byte `[this+0x42]`; the mode-gated query itself is now bounded
+  as one runtime enable byte on that local object family. One level higher, `0x00474450` constructs
   the collection rooted at vtable `0x005ce4a8` with fixed parameters `(0,0,0,0x14,0x0a,0,0)`, and
   bootstrap caller `0x004487a9` stores that collection into global `0x006cea50`. The collection's
   entry path is also bounded now: `0x004744a0` seeds a stack-local temporary entry through
@@ -3579,7 +3586,8 @@ The low helper strip beneath that shared family is tighter now too: `0x0052ecd0`
   commands, direct keyboard turn/pan/zoom bindings, the `TrackLay.win` and `StationPlace.win`
   world-command surfaces, and a frame-owned hover or focus-target transition branch all feed the
   same shell-controller-backed path. The remaining uncertainty has moved farther from basic
-  ownership: the hover-target branch clearly exists, and `0x07d6` now looks like the shared
+  ownership only in the per-tool sense: the hover-target branch clearly exists, `0x07d6` now looks
+  like the shared
   main-world interaction surface rather than a generic detail button for one tool family only. One
   more shell-side consumer is bounded now too: `0x004bc350` is a world-surface brush handler over
   that same `0x07d6` control plus the adjacent mode family `0x0faa..0x0faf` and ordinal strip
@@ -3636,6 +3644,6 @@ The low helper strip beneath that shared family is tighter now too: `0x0052ecd0`
   state through `0x004f5a80`, while `0x004f7ada` is the later drag-active path that first
   allocates a temporary occupancy mask before rebuilding and then conditionally mirrors that
   mask through `world_rebuild_active_preview_or_tool_overlay_surface_and_publish_normalized_bounds`
-  `0x00450520` on the world-mode-`0x17` side path. So the remaining uncertainty
-  has narrowed again from family ownership to the exact meaning of a few per-mode scalar and
-  token lanes, not to whether `PaintTerrain.win` itself is still a mixed shell/world owner.
+  `0x00450520` on the world-mode-`0x17` side path. The remaining local lanes can therefore be
+  carried conservatively as PaintTerrain per-mode scalar and token bands beneath that already-
+  grounded mixed shell/world ownership strip, not as another ownership seam.