Bound infrastructure child-stream restore owner

crates/rrt-runtime/src/smp.rs

@@ -3887,6 +3887,7 @@ fn build_infrastructure_asset_trace_report(
         .count();
     let atlas_candidate_consumers = vec![
         "0x0048a1e0 infrastructure child attach helper".to_string(),
+        "0x0048dcf0 infrastructure tagged child-stream restore outer owner".to_string(),
         "0x0048dd50 infrastructure child rebuild loop".to_string(),
         "0x00490a3c infrastructure payload attach helper".to_string(),
         "0x004559d0 infrastructure tagged string-triplet serializer".to_string(),
@@ -3902,6 +3903,7 @@ fn build_infrastructure_asset_trace_report(
         "child list [this+0x75] under the Infrastructure owner".to_string(),
     ];
     let known_bridge_helpers = vec![
+        "0x00455a50 raw vtable slot +0x40 dispatch wrapper with global bridge reset".to_string(),
         "0x005395d0 shared child-attach list owner".to_string(),
         "0x00539530 shared position-lane seed helper".to_string(),
         "0x0053a5b0 shared third position-lane seed helper".to_string(),
@@ -3910,9 +3912,9 @@ fn build_infrastructure_asset_trace_report(
         "0x0048e140 / 0x0048e160 / 0x0048e180 route-entry resolver helpers".to_string(),
     ];
     let next_owner_questions = vec![
-        "Do the 0x38a5 compact-prefix/name-pair groups feed the first-child triplet clone lane, the caller-supplied payload-stem lane, or only later route/local-runtime refresh?".to_string(),
+        "Which upstream owner materializes the tagged child stream that 0x0048dcf0 restores before the later 0x0048dd50 rebuild loop runs?".to_string(),
-        "Is cached primary-child slot [this+0x248] the first owner-visible bridge from the side-buffer seam into route-entry rebuild?".to_string(),
+        "Does the 0x38a5 compact-prefix/name-pair seam feed that upstream child-stream materializer, the direct 0x00490a3c payload-stem path, or only later route/local-runtime refresh?".to_string(),
-        "Which child fields or grouped rows absorb the side-buffer payload before 0x00448a70/0x00493660/0x0048b660 become relevant?".to_string(),
+        "Is cached primary-child slot [this+0x248] the first owner-visible bridge from the restored child stream into route-entry rebuild?".to_string(),
     ];
     let candidate_consumer_hypotheses = vec![
         SmpServiceConsumerHypothesis {
@@ -3927,6 +3929,7 @@ fn build_infrastructure_asset_trace_report(
             },
             candidate_consumers: vec![
                 "0x0048a1e0 infrastructure child attach helper".to_string(),
+                "0x0048dcf0 infrastructure tagged child-stream restore outer owner".to_string(),
                 "0x0048dd50 infrastructure child rebuild loop".to_string(),
                 "0x00490a3c infrastructure payload attach helper".to_string(),
             ],
@@ -3940,10 +3943,12 @@ fn build_infrastructure_asset_trace_report(
                 "atlas already bounds these helpers under the literal Infrastructure owner".to_string(),
                 "the side-buffer corpus is disjoint from the placed-structure triplet corpus, so a separate child/rebuild family is more plausible than a compact alias".to_string(),
                 "direct disassembly now shows 0x0048a1e0 cloning the first child triplet bands through 0x52e880/0x52e720, destroying the prior child, seeding a new literal Infrastructure child through 0x455b70 with payload seed 0x5c87a8, attaching through 0x5395d0 or 0x53a5d0, and republishing the two bands through 0x52e8b0/0x530720".to_string(),
+                "direct disassembly now also shows the outer owner at 0x0048dcf0 reading a child count plus optional primary-child ordinal from the tagged stream through 0x531150, zeroing [this+0x08], dispatching each fresh child through 0x455a50 -> vtable slot +0x40, culling ordinals above 5, and restoring cached primary-child slot [this+0x248] from the saved ordinal".to_string(),
+                "the smaller attach primitive 0x00490a3c no longer looks like the semantic fork by itself: it just allocates one literal Infrastructure child, seeds it through 0x455b70 with caller-provided stem input, attaches it through 0x5395d0, seeds position lanes through 0x539530/0x53a5b0, and optionally caches it as primary child".to_string(),
             ],
             blockers: vec![
-                "exact compact-prefix regime semantics".to_string(),
+                "which upstream owner materializes the tagged child stream that 0x0048dcf0 consumes".to_string(),
-                "which child fields or grouped rows consume the side-buffer payload".to_string(),
+                "whether the 0x38a5 compact-prefix/name-pair seam feeds that materializer or only a separate payload/cache lane".to_string(),
             ],
         },
         SmpServiceConsumerHypothesis {
@@ -22001,7 +22006,7 @@ mod tests {
         assert!(trace.side_buffer_present);
         assert_eq!(trace.triplet_alignment_overlap_count, 0);
         assert_eq!(trace.known_owner_bridge_fields.len(), 4);
-        assert_eq!(trace.known_bridge_helpers.len(), 5);
+        assert_eq!(trace.known_bridge_helpers.len(), 6);
         assert_eq!(trace.next_owner_questions.len(), 3);
         assert_eq!(trace.candidate_consumer_hypotheses.len(), 3);
         assert_eq!(

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

@@ -2908,6 +2908,12 @@ The low helper strip beneath that shared family is tighter now too: `0x0052ecd0`
   `Infrastructure` children one ordinal at a time, tears down the higher extras above ordinal `5`,
   refreshes cached primary-child slot `[this+0x248]` when needed, and finishes with the same
   world-cell and route-side follow-on family around `0x00448a70`, `0x00493660`, and `0x0048b660`.
+  The outer owner above that loop is bounded now too: `0x0048dcf0` reads a child count plus one
+  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. So the rebuild
+  strip is consuming an already-materialized child stream rather than parsing the compact side
+  buffer directly.
   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
@@ -2918,8 +2924,10 @@ The low helper strip beneath that shared family is tighter now too: `0x0052ecd0`
   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
+  no longer whether this strip owns the child/rebuild seam at all, but which upstream owner
-  groups feed the clone-or-payload choice before the later route/local-runtime family runs.
+  materializes the child stream that `0x0048dcf0` consumes, and whether the side-buffer prefix
+  groups feed that materializer, the direct payload-stem lane, or only the later
+  route/local-runtime family.
   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

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