Ground blocked owner strips with direct disassembly

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

@@ -73,7 +73,18 @@ 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. That narrows the next closure target
+  shell-facing fallback above the same queue family now too. Direct disassembly tightens the
+  bridge below that owner as well: `0x004358d0` first requires `[region+0x276]`, then drives two
+  separate `0x00420030` gate calls plus one `0x00420280` first-match selector before resolving the
+  linked company through `0x0047efe0`; only after that does it emit the success-side company/stat
+  update or the one-shot fallback notice. The peer helper itself is more concrete now too:
+  `0x00420030` walks collection `0x006cec20`, applies the class match through `0x0042b2d0`, uses
+  the optional linked-company filter through `0x0047efe0`, keeps the station-or-transit gate
+  `0x0047fd50`, and then tests the candidate status branch through `0x0047de00 -> 0x0040c990`
+  before reporting success. The paired selector `0x00420280` is the same scan with the same
+  filters, but returns the first matching site id instead of a boolean. So the remaining region gap
+  is now squarely the persisted latch/id seam, not the live peer/service logic itself.
+  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

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

@@ -2911,6 +2911,16 @@ 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
+  direct disassembly now makes that strip more concrete than the earlier structural note alone:
+  `0x0048a1e0` really does clone the first child through paired triplet readers
+  `0x0052e880/0x0052e720`, destroys the prior child through vtable slot `+0x18(0)`, allocates the
+  new `0x23a` object, seeds it through `0x00455b70` with literal payload seed `0x005c87a8`, and
+  then republishes the two sampled triplet bands through `0x0052e8b0` and `0x00530720` after
+  attaching through `0x005395d0`. The non-clone branch still seeds the same literal
+  `Infrastructure` child but attaches through `0x0053a5d0` instead. That means the next unknown is
+  no longer whether this strip owns the child/rebuild seam at all, but which side-buffer prefix
+  groups feed the clone-or-payload choice before the later route/local-runtime family runs.
+  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