Split acquisition replay consumers from rehydrators

crates/rrt-runtime/src/smp.rs

@@ -4719,7 +4719,7 @@ fn build_periodic_company_service_trace_report(
                 "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 replay family above live placed structures".to_string(),
                 "0x004133b0 rebuilds cloned local-runtime records through 0x0040e450 and 0x0040ee10 only republishes local position/scalar triplets before 0x0040e360".to_string(),
-                "direct local replay-strip inspection now tightens that further: 0x0040ee10 only reads cached source lane [site+0x3cc] in the checked range, while the bounded 0x00480710 neighborhood is working from [site+0x04], [site+0x08], and [site+0x3cc] rather than [site+0x276] or [site+0x310/+0x338/+0x360]".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(),
                 "direct local writer census now shows the grounded [site+0x276] write side clustering under live mutation families such as 0x004269b0 / 0x00426a10, the create-side 0x0040ef10 / 0x0040f6d0 strip, and the bulk reassignment families 0x00426dce..0x00426ea1 and 0x00430040..0x004300d6 rather than under the known replay strip".to_string(),
                 "direct local control-flow reconstruction now shows those same writer families hanging under the 0x00431b20 opcode dispatcher over 0x0061039c: opcodes 0x04..0x07 dispatch to 0x00430040, opcodes 0x08/0x10..0x13 dispatch to 0x00426d60, and opcodes 0x0d/0x16 dispatch to 0x0042fc90".to_string(),
                 "0x0042fc90 itself iterates the live placed-structure collection 0x0062b26c, filters rows through 0x0040c990 plus optional company match [site+0x276], and then dispatches row vtable slot +0x70, which keeps that branch on the live application side rather than replay".to_string(),
@@ -4845,6 +4845,8 @@ fn build_periodic_company_service_trace_report(
         "0x00444690 late world bring-up caller of 0x004133b0 placed-structure local-runtime replay"
             .to_string(),
         "0x004133b0 placed-structure local-runtime replay owner draining queued site ids through 0x0040e450 and sweeping live sites through 0x0040ee10".to_string(),
+        "0x0040e360..0x0040edf6 broader replay continuation consuming [site+0x2a8/+0x2a4/+0x276] around 0x0040d230 / 0x0040d1f0 / 0x00480710 / 0x00426b10 / 0x00455860"
+            .to_string(),
         "0x0040e450 queued site-id cloned local-runtime replay helper".to_string(),
         "0x0040ee10 live-site position/scalar refresh helper reaching 0x0040edf6 -> 0x00480710 and 0x0040e360".to_string(),
         "0x00480710 linked-site runtime side-buffer and route-entry-anchor refresh owner"
@@ -28110,7 +28112,7 @@ mod tests {
         let trace = build_periodic_company_service_trace_report(&analysis);
         assert_eq!(trace.selected_company_id, Some(7));
         assert_eq!(trace.atlas_candidate_consumers.len(), 9);
-        assert_eq!(trace.known_bridge_helpers.len(), 68);
+        assert_eq!(trace.known_bridge_helpers.len(), 69);
         assert_eq!(trace.next_owner_questions.len(), 5);
         assert_eq!(trace.companies.len(), 1);
         assert_eq!(
@@ -28284,9 +28286,14 @@ mod tests {
                 .iter()
                 .any(|line| line.contains("0x0040ee10")
                     && line.contains("[site+0x3cc]")
+                    && line.contains("0x0040e360..0x0040edf6")
+                    && line.contains("[site+0x2a8]")
+                    && line.contains("[site+0x2a4]")
+                    && line.contains("[site+0x276]")
                     && line.contains("0x00480710")
-                    && line.contains("[site+0x04]")
+                    && line.contains("0x00426b10")
-                    && line.contains("[site+0x08]"))
+                    && line.contains("0x00455860")
+                    && line.contains("reads/queries"))
         );
         assert!(
             trace.near_city_acquisition_projection_hypotheses[1]
@@ -28867,6 +28874,12 @@ mod tests {
                 .iter()
                 .any(|line| line.contains("0x00444690") && line.contains("0x004133b0"))
         );
+        assert!(trace.known_bridge_helpers.iter().any(
+            |line| line.contains("0x0040e360..0x0040edf6")
+                && line.contains("[site+0x2a8/+0x2a4/+0x276]")
+                && line.contains("0x00426b10")
+                && line.contains("0x00455860")
+        ));
         assert!(
             trace
                 .known_bridge_helpers

docs/rehost-queue.md

@@ -108,10 +108,14 @@ Working rule:
     position/scalar triplets, but current evidence still does not tie that replay family directly
     to `[site+0x276]`
   - the same replay strip is narrower than before now:
-    direct local inspection shows `0x0040ee10` only reading cached source lane `[site+0x3cc]`
+    direct local inspection now splits it more precisely:
-    in the checked range, while the bounded `0x00480710` neighborhood is working from
+    `0x0040ee10` itself only reads cached source lane `[site+0x3cc]` in the checked range, and
-    `[site+0x04]`, `[site+0x08]`, and `[site+0x3cc]` rather than `[site+0x276]` or the
+    the bounded `0x00480710` neighborhood is working from `[site+0x04]`, `[site+0x08]`, and
-    cached tri-lane
+    `[site+0x3cc]`; but the broader immediate continuation `0x0040e360..0x0040edf6` still
+    consumes `[site+0x2a8]`, `[site+0x2a4]`, and `[site+0x276]` around
+    `0x0040d230 / 0x0040d1f0 / 0x00480710 / 0x00426b10 / 0x00455860`, so the replay family is
+    narrowed rather than ruled out for owner-company rehydration; in the checked range those
+    `[site+0x276]` uses are still reads/queries rather than a direct rehydrating store
   - the second is narrower in the same way:
     the checked-in `0x36b1/0x36b2/0x36b3` triplet seam and the
     `0x4a9d/0x4a3a/0x4a3b` side-buffer seam still do not serialize `[site+0x310/+0x338/+0x360]`