Bind infrastructure side-buffer load path

crates/rrt-runtime/src/smp.rs

@@ -3886,6 +3886,7 @@ fn build_infrastructure_asset_trace_report(
         .filter(|summary| summary.primary_name.contains("TrackCap"))
         .count();
     let atlas_candidate_consumers = vec![
+        "0x00493be0 infrastructure tagged side-buffer collection load owner".to_string(),
         "0x0048a1e0 infrastructure child attach helper".to_string(),
         "0x0048dcf0 infrastructure tagged child-stream restore outer owner".to_string(),
         "0x0048dd50 infrastructure child rebuild loop".to_string(),
@@ -3903,6 +3904,7 @@ fn build_infrastructure_asset_trace_report(
         "child list [this+0x75] under the Infrastructure owner".to_string(),
     ];
     let known_bridge_helpers = vec![
+        "0x00493be0 tagged 0x38a5/0x38a6/0x38a7 collection load owner".to_string(),
         "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(),
@@ -3912,8 +3914,8 @@ fn build_infrastructure_asset_trace_report(
         "0x0048e140 / 0x0048e160 / 0x0048e180 route-entry resolver helpers".to_string(),
     ];
     let next_owner_questions = vec![
-        "Which upstream owner materializes the tagged child stream that 0x0048dcf0 restores before the later 0x0048dd50 rebuild loop runs?".to_string(),
+        "Which exact 0x38a5 rows or compact-prefix regimes feed the child count and optional primary-child ordinal that 0x0048dcf0 restores before the later rebuild loop runs?".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 0x38a5 embedded name-pair groups survive into the per-child vtable +0x40 payload callbacks dispatched through 0x00455a50?".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![
@@ -3928,6 +3930,7 @@ fn build_infrastructure_asset_trace_report(
                 "possible_consumer_family".to_string()
             },
             candidate_consumers: vec![
+                "0x00493be0 infrastructure tagged side-buffer collection load owner".to_string(),
                 "0x0048a1e0 infrastructure child attach helper".to_string(),
                 "0x0048dcf0 infrastructure tagged child-stream restore outer owner".to_string(),
                 "0x0048dd50 infrastructure child rebuild loop".to_string(),
@@ -3942,13 +3945,15 @@ 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 0x00493be0 opening tag family 0x38a5/0x38a6/0x38a7, reading one shared dword into the owner-local 0x90/0x94 lane, iterating each live collection entry, and dispatching every loaded infrastructure record through 0x0048dcf0 before the later follow-on owners run".to_string(),
+                "local .rdata at 0x005cfd00 now also proves the infrastructure child table uses the shared tagged callback strip directly: slot +0x40 = 0x455fc0, slot +0x48 = 0x455870, and slot +0x4c = 0x455930".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![
-                "which upstream owner materializes the tagged child stream that 0x0048dcf0 consumes".to_string(),
+                "which exact 0x38a5 rows or compact-prefix regimes map to the child count, saved primary-child ordinal, and per-child shared tagged callback records".to_string(),
-                "whether the 0x38a5 compact-prefix/name-pair seam feeds that materializer or only a separate payload/cache lane".to_string(),
+                "which restored child fields or grouped rows retain the 0x38a5 embedded name-pair semantics before route/local-runtime follow-ons take over".to_string(),
             ],
         },
         SmpServiceConsumerHypothesis {
@@ -3965,10 +3970,11 @@ fn build_infrastructure_asset_trace_report(
             ],
             evidence: vec![
                 "atlas already bounds the serializer/load strip around the Infrastructure owner and the same 0x55f1/0x55f2/0x55f3 tag family".to_string(),
+                "local .rdata at 0x005cfd00 now proves the infrastructure child vtable points straight at 0x455fc0/0x455870/0x455930 for the load, triplet-restore, and serializer slots".to_string(),
                 "the save-side side-buffer carries embedded dual-name rows plus compact prefixes, which is compatible with a serializer-side bridge".to_string(),
             ],
             blockers: vec![
-                "whether the side-buffer is a direct serialized payload or one rebuild/cache layer above it".to_string(),
+                "which exact 0x38a5 rows belong to shared 0x55f1/0x55f2/0x55f3 child records versus outer collection metadata".to_string(),
             ],
         },
         SmpServiceConsumerHypothesis {
@@ -22006,7 +22012,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(), 6);
+        assert_eq!(trace.known_bridge_helpers.len(), 7);
         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

@@ -2914,6 +2914,16 @@ The low helper strip beneath that shared family is tighter now too: `0x0052ecd0`
   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 upstream handoff is explicit now too: `0x00493be0` is the tagged collection load owner over
+  `0x38a5/0x38a6/0x38a7`, and it feeds each live infrastructure record straight into
+  `0x0048dcf0` after restoring one shared owner-local dword into the `0x90/0x94` lane. That means
+  the `0x38a5` side-buffer seam is now a proven direct upstream feed into the child-stream restore
+  owner rather than only a candidate cache or serializer-side neighbor.
+  The child loader family is explicit now too: local `.rdata` at `0x005cfd00` proves the
+  `Infrastructure` child vtable uses the shared tagged callback strip directly, with
+  `+0x40 = 0x00455fc0`, `+0x48 = 0x00455870`, and `+0x4c = 0x00455930`. So the remaining
+  infrastructure problem is row-to-record mapping inside the `0x38a5` stream, not identifying the
+  per-child loader family.
   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
@@ -2924,10 +2934,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 upstream owner
+  no longer whether this strip owns the child/rebuild seam at all, but which exact `0x38a5` rows
-  materializes the child stream that `0x0048dcf0` consumes, and whether the side-buffer prefix
+  or compact-prefix regimes map to the child count, saved primary-child ordinal, and per-child
-  groups feed that materializer, the direct payload-stem lane, or only the later
+  `+0x40` payload callbacks inside that direct load path, and which restored child fields still
-  route/local-runtime family.
+  retain those embedded name-pair semantics 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

docs/rehost-queue.md

@@ -51,12 +51,24 @@ Working rule:
   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 upstream handoff is grounded now too: `0x00493be0` is the tagged collection load owner over
+  `0x38a5/0x38a6/0x38a7`, and it feeds each live infrastructure record straight into
+  `0x0048dcf0` after restoring one shared owner-local dword into the `0x90/0x94` lane. So the
+  remaining infrastructure question is no longer whether `0x38a5` reaches the child-stream restore
+  path at all; it is which exact rows or compact-prefix regimes map to the child count, saved
+  primary-child ordinal, and per-child `+0x40` payload callbacks inside that direct path.
+- The child loader identity is closed now too: local `.rdata` at `0x005cfd00` proves the
+  `Infrastructure` child vtable uses the shared tagged callback strip directly, with
+  `+0x40 = 0x00455fc0`, `+0x48 = 0x00455870`, and `+0x4c = 0x00455930`. So the remaining
+  infrastructure frontier is row-to-record mapping inside `0x38a5`, not “which loader family does
+  this child use?”.
 - 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
+  maps the direct `0x38a5` rows into the child count, primary-child ordinal, and per-child payload
-  or only a separate payload/cache lane.
+  callbacks consumed by `0x0048dcf0`, and which restored child fields still retain those embedded
+  name-pair semantics before route/local-runtime follow-ons take over.
 - 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