Order placed-structure restore-side stages

crates/rrt-runtime/src/smp.rs

@@ -4757,6 +4757,7 @@ fn build_periodic_company_service_trace_report(
                 "[site+0x2a4] self-id meaning is grounded through 0x0041f7e0 / 0x0041f810 / 0x0041f850".to_string(),
                 "0x004269b0 resolves the chosen site id through placed-structure collection 0x0062b26c before mutating the live row, so [site+0x2a4] is reconstructible from collection identity rather than a separate serializer-owned selector".to_string(),
                 "0x00444690 -> 0x004133b0 -> 0x0040ee10 is the current checked-in ordinary bring-up replay family above live placed structures".to_string(),
+                "the ordinary restore-side staging order is tighter now too: world bring-up calls 0x00413280 first for tagged 0x36b1/0x36b2/0x36b3 stream load at 0x00444467, refreshes dynamic side buffers through 0x00481210 at 0x004444d8, and only later enters 0x004133b0 at 0x00444690 for queued local-runtime replay plus 0x0040ee10".to_string(),
                 "0x004133b0 rebuilds cloned local-runtime records through 0x0040e450 and 0x0040ee10 only republishes local position/scalar triplets before 0x0040e360".to_string(),
                 "the ordinary bring-up strip stays separate from the constructor/finalize family too: after 0x00444690 -> 0x004133b0 the world restore continues through later route-entry/grid/tagged refresh owners rather than re-entering 0x004134d0 / 0x0040f6d0 / 0x0040ef10 for already-restored rows".to_string(),
                 "direct local replay-strip inspection now splits that family more precisely: bounded 0x0040ee10 itself only reads cached source lane [site+0x3cc], and the bounded 0x00480710 neighborhood is working from [site+0x04], [site+0x08], and [site+0x3cc]; the broader immediate continuation 0x0040e360..0x0040edf6 still consumes [site+0x2a8], [site+0x2a4], and [site+0x276] around 0x0040d230 / 0x0040d1f0 / 0x00480710 / 0x00426b10 / 0x00455860, but in the checked range those [site+0x276] uses are still reads/queries rather than a direct rehydrating store".to_string(),
@@ -4782,6 +4783,7 @@ fn build_periodic_company_service_trace_report(
                 "the explicit store census now also rules down the remaining obvious non-transport writes, so the missing ordinary restored-row owner seam likely sits outside the currently bounded direct allocator/finalize/store families".to_string(),
                 "the paired collection-side triplet serializer 0x00413440 is ruled down too, so the missing ordinary restored-row owner seam likely sits outside the currently bounded direct allocator/finalize/store families and the tagged 0x36b1/0x36b2/0x36b3 load-save strip".to_string(),
                 "the load-side stream owner 0x00413280 is ruled down to cached-source/candidate replay through vtable slot +0x40 and 0x0040ce60, so the missing ordinary restored-row owner seam still sits beyond the current stream-load bridge too".to_string(),
+                "the checked ordinary restore ordering is ruled down too: 0x00413280 stream load, 0x00481210 dynamic side-buffer refresh, and 0x004133b0 local-runtime replay all sit on the bring-up strip without re-entering 0x004134d0 / 0x0040f6d0 / 0x0040ef10 for already-restored rows".to_string(),
             ],
         },
         SmpServiceConsumerHypothesis {
@@ -28488,6 +28490,16 @@ mod tests {
                 .any(|line| line.contains("0x00444690 -> 0x004133b0")
                     && line.contains("ordinary bring-up replay family"))
         );
+        assert!(
+            trace.near_city_acquisition_projection_hypotheses[0]
+                .evidence
+                .iter()
+                .any(|line| line.contains("0x00444467")
+                    && line.contains("0x00413280")
+                    && line.contains("0x004444d8")
+                    && line.contains("0x00481210")
+                    && line.contains("0x00444690"))
+        );
         assert!(
             trace.near_city_acquisition_projection_hypotheses[0]
                 .evidence
@@ -28725,6 +28737,14 @@ mod tests {
                     && line.contains("0x0040ce60")
                     && line.contains("stream-load bridge"))
         );
+        assert!(
+            trace.near_city_acquisition_projection_hypotheses[0]
+                .blockers
+                .iter()
+                .any(|line| line.contains("0x00481210")
+                    && line.contains("0x004133b0")
+                    && line.contains("0x0040ef10"))
+        );
         assert_eq!(
             trace
                 .near_city_acquisition_runtime_backed_input_families

docs/rehost-queue.md

@@ -210,6 +210,11 @@ Working rule:
     sweeps live rows through `0x0040ee10`; after that, bring-up proceeds into later route-entry,
     grid, and tagged refresh owners rather than re-entering the constructor/finalize family
     `0x004134d0 / 0x0040f6d0 / 0x0040ef10`
+  - the ordinary restore staging order is explicit now too:
+    world bring-up calls the tagged `0x36b1/0x36b2/0x36b3` stream-load owner `0x00413280` at
+    `0x00444467`, refreshes the placed-structure dynamic side buffers through `0x00481210` at
+    `0x004444d8`, and only later enters the queued local-runtime replay owner
+    `0x00444690 -> 0x004133b0 -> 0x0040ee10`
   - the broader load-side stream owner is separate too:
     `0x00413280` is the actual tagged `0x36b1/0x36b2/0x36b3` stream-load owner, dispatching
     per-entry vtable slot `+0x40`; current local recovery still only grounds that seam through the