Ground infrastructure child construction strip

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

@@ -3057,6 +3057,19 @@ The low helper strip beneath that shared family is tighter now too: `0x0052ecd0`
   then closes `0x55f3`. So the remaining infrastructure problem is row-to-record mapping inside
   the `0x38a5` stream and which chooser/seed values reach those string lanes and footer bytes, not
   identifying the per-child loader family.
+  The source side is tighter now too. The paired chooser siblings already bounded above this seam
+  call `0x00490960` directly beside `0x0048a340/0x0048f4c0/0x00490200`, and `0x00490960` copies
+  selector fields into the child object (`[this+0x219]`, `[this+0x251]`, bit `0x20` in
+  `[this+0x24c]`, and `[this+0x226]`), allocates a fresh `0x23a` `Infrastructure` child, seeds it
+  through `0x00455b70` with caller-supplied stem input plus fixed literal `Infrastructure` at
+  `0x005cfd74`, attaches it through `0x005395d0`, seeds position lanes through
+  `0x00539530/0x0053a5b0`, and can cache it as primary child in `[this+0x248]`. The sibling
+  `0x00490200` then reads the same seeded lanes `[this+0x206/+0x20a/+0x20e]` back through the live
+  route collection at `0x006cfca8`, compares them against the current owner using
+  `[this+0x216/+0x218/+0x201/+0x202]`, and behaves like a route/link comparator layered above the
+  same child payload fields that `0x004559d0` later serializes. So the remaining infrastructure
+  problem is which chooser branches feed `0x00490960` which stem/selector tuples for each
+  grounded save-side class, not where the child payload lanes come from at all.
   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

docs/rehost-queue.md

@@ -83,6 +83,21 @@ Working rule:
   dispatch slot `+0x4c`, run `0x0052ec50`, and close `0x55f3`. So the remaining infrastructure
   frontier is no longer “which slot does `0x00455a40` jump to?”; it is which chooser/seed values
   reach those string lanes and the trailing footer path.
+- That source side is narrower now too: direct disassembly shows the paired chooser siblings
+  calling `0x00490960` directly beside `0x0048a340/0x0048f4c0/0x00490200`, and `0x00490960`
+  copies selector fields into the child object (`[this+0x219]`, `[this+0x251]`, bit `0x20` in
+  `[this+0x24c]`, and `[this+0x226]`), allocates a fresh `0x23a` `Infrastructure` child, seeds it
+  through `0x00455b70` with caller-supplied stem input plus fixed literal `Infrastructure` at
+  `0x005cfd74`, attaches it through `0x005395d0`, seeds position lanes through
+  `0x00539530/0x0053a5b0`, and can cache it as primary child in `[this+0x248]`. The remaining
+  problem is no longer “where do the child payload lanes come from?” but “which chooser branches
+  feed `0x00490960` which caller stem and selector tuple for each grounded save-side class?”.
+- The sibling `0x00490200` is tighter now too: it reads the seeded lanes
+  `[this+0x206/+0x20a/+0x20e]` back through the live route collection at `0x006cfca8`, compares
+  them against the current owner using `[this+0x216/+0x218/+0x201/+0x202]`, and behaves like a
+  route/link comparator layered above the same child payload lanes that `0x004559d0` later
+  serializes. So the next infrastructure pass should treat `0x00490960` as the source owner and
+  `0x00490200` as a consumer of the same seeded lanes, not as separate unexplained seams.
 - The smaller helper `0x00490a3c` is narrower now too: it allocates one literal `Infrastructure`
   child, seeds it through `0x00455b70` with caller-provided stem input, attaches it through
   `0x005395d0`, seeds position lanes through `0x00539530/0x0053a5b0`, and optionally caches it as