Refine next owner questions for blocked seams

docs/control-loop-atlas/post-load-generation-paintterrain-and-save-load-restore.md

@@ -73,7 +73,15 @@ The same brush strip is tighter now too:
   `[region+0x316]` is still clear, the same owner publishes one alternate one-shot notice from the
   same amount and region scalar before setting `[region+0x316]`. So the pending-region bonus lane
   is no longer just a queued setup artifact: it has a concrete later service owner and an explicit
-  shell-facing fallback above the same queue family now too. `0x00438710` is the recurring queue
+  shell-facing fallback above the same queue family now too. That narrows the next closure target
+  as well: ordinary-save probes can stop treating `[world+0x66a6]` persistence as the primary
+  blocker, because the checked-in negative results on `q.gms`, `p.gms`, and `Autosave.gms` now make
+  the pending-bonus owner plus its peer/linkage strip the first safe static target instead. The
+  next pass should therefore ask only three concrete questions: which persisted owner seam rebuilds
+  or restores `[region+0x25e/+0x276/+0x302/+0x316]`, which stable region id or class discriminator
+  survives save/load strongly enough to drive `0x004358d0`, and how far the city-connection peer
+  helpers `0x00420030/0x00420280` plus linked-company resolver `0x0047efe0` can be reused
+  directly before the transient queued-notice family matters again. `0x00438710` is the recurring queue
   service owner above `[world+0x66a6]` and `[world+0x66aa]`; the short dirty-mark path is tighter
   now as well, because it checks the per-node promotion-latch dword `[node+0x0c] == 1` rather than
   reusing the queue kind field. `0x00438840` is the tiny

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

@@ -2911,6 +2911,18 @@ The low helper strip beneath that shared family is tighter now too: `0x0052ecd0`
   The smaller attach helper `0x00490a3c` is now bounded too: it conditionally allocates one
   `Infrastructure` child from a caller-supplied payload stem, attaches it to the current owner, and
   then seeds three caller-supplied position lanes through `0x00539530` and `0x0053a5b0`. The
+  remaining closure target above the grounded `0x38a5` side-buffer seam is therefore narrower now:
+  the next safe static pass should start at this exact attach/rebuild strip, not at the whole
+  placed-structure family. The key open questions are whether the compact-prefix/name-pair groups
+  feed the first-child triplet clone lane, the caller-supplied payload-stem lane, or only the
+  later route/local-runtime follow-on family; whether cached primary-child slot `[this+0x248]`
+  becomes the first owner-visible bridge between those side-buffer groups and route-entry rebuild;
+  and which child fields or grouped rows absorb the side-buffer payload before
+  `0x00448a70/0x00493660/0x0048b660` become relevant. That keeps the top-ranked next mapping target
+  explicit as `0x0048a1e0`, `0x0048dd50`, and `0x00490a3c`, with the serializer/load companions and
+  route/local-runtime follow-ons staying secondary until one concrete child-consumer bridge is
+  grounded.
+  The
   direct route-entry side of the same family is no longer anonymous either: `0x0048e140`,
   `0x0048e160`, and `0x0048e180` are the three direct resolvers over owner fields
   `[this+0x206/+0x20a/+0x20e]` into the live route-entry collection `0x006cfca8`. Another shared

docs/rehost-queue.md

@@ -33,6 +33,13 @@ Working rule:
   current best hypothesis as the child attach/rebuild strip
   (`0x0048a1e0`, `0x0048dd50`, `0x00490a3c`), with the serializer/load companions next and the
   route/local-runtime follow-on family explicitly secondary.
+- For that top-ranked infrastructure strip, treat the next pass as three exact owner questions
+  rather than a general “map the consumer” task: whether the `0x38a5` compact-prefix/name-pair
+  groups feed the first-child triplet clone lane, the caller-supplied payload-stem lane, or only a
+  later route/local-runtime refresh lane; whether cached primary-child slot `[this+0x248]` is the
+  first owner-visible bridge from the side-buffer seam into route-entry rebuild; and which child
+  fields or grouped rows absorb the side-buffer payload before `0x00448a70/0x00493660/0x0048b660`
+  become relevant.
 - Reconstruct the save-side region record body on top of the newly corrected non-direct tagged
   region seam (`0x5209/0x520a/0x520b`, stride hint `0x06`, `Marker09` record stems) now that the
   `0x55f3` payload is known to be fully consumed by the embedded profile collection on grounded
@@ -56,6 +63,12 @@ Working rule:
   (`0x004358d0`) plus the peer/linkage strip (`0x00420030/0x00420280`, `0x0047efe0`), with the
   transient producer/queue family explicitly secondary and the queued kind-`7` modal dispatch kept
   as shell-adjacent reference only.
+- For that top-ranked region strip, treat the next pass as three exact owner questions too: which
+  persisted owner seam restores or rebuilds `[region+0x25e/+0x276/+0x302/+0x316]`, which stable
+  region id or class discriminator survives save/load strongly enough to drive `0x004358d0`, and
+  how far the grounded city-connection peer/linkage helpers
+  (`0x00420030/0x00420280`, `0x0047efe0`) can be reused directly before the transient queued-notice
+  family matters again.
 - Reconstruct the save-side placed-structure collection body on top of the newly grounded
   `0x36b1/0x36b2/0x36b3` header seam so the blocked city-connection / linked-transit branch can
   stop depending on atlas-only placed-structure and local-runtime refresh notes, especially the