Bound infrastructure child-stream restore owner

docs/rehost-queue.md

@@ -45,6 +45,18 @@ Working rule:
   through `0x0052e8b0/0x00530720` after attaching through `0x005395d0`; the non-clone branch
   attaches through `0x0053a5d0`. So the next unknown is no longer whether this strip owns the
   child/rebuild seam, but which `0x38a5` compact-prefix groups drive the clone-vs-payload choice.
+- The outer rebuild owner is tighter now too: `0x0048dcf0` reads a child count plus optional
+  primary-child ordinal from the tagged stream through `0x00531150`, zeroes `[this+0x08]`,
+  dispatches each fresh child through `0x00455a50 -> vtable slot +0x40`, culls ordinals above `5`,
+  and restores cached primary-child slot `[this+0x248]` from the saved ordinal. That means the
+  child/rebuild loop is consuming an already-materialized child stream rather than parsing the
+  `0x38a5` compact-prefix seam directly.
+- 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
+  the primary child. So the next concrete infrastructure question is which upstream owner
+  materializes the child stream that `0x0048dcf0` consumes, and whether `0x38a5` feeds that owner
+  or only a separate payload/cache lane.
 - 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