Ground infrastructure child construction strip

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