Correct startup compact effect ownership

crates/rrt-runtime/src/smp.rs

@@ -4785,7 +4785,7 @@ fn build_periodic_company_service_trace_report(
                 "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(),
-                "the grouped opcode dispatcher 0x00431b20 is ruled down too: current direct caller census only reaches it from scenario runtime-effect service 0x004323a0 -> 0x00432f40 via 0x00432317, so 0x0061039c currently reads as a live runtime-effect application lane rather than the missing persisted restore owner for [site+0x276]".to_string(),
+                "the grouped opcode dispatcher 0x00431b20 is narrower rather than ruled down now: it is still only reached through scenario runtime-effect service 0x004323a0 -> 0x00432f40 via 0x00432317, but that service loop is itself called from world bring-up at 0x00444d92 with trigger kind 8 under shell-profile latch [0x006cec7c+0x97], so 0x0061039c reads as a startup-time live runtime-effect application lane rather than an ordinary tagged restore owner".to_string(),
             ],
         },
         SmpServiceConsumerHypothesis {
@@ -28766,7 +28766,10 @@ mod tests {
                 .any(|line| line.contains("0x00431b20")
                     && line.contains("0x004323a0")
                     && line.contains("0x00432f40")
-                    && line.contains("0x00432317"))
+                    && line.contains("0x00432317")
+                    && line.contains("0x00444d92")
+                    && line.contains("kind 8")
+                    && line.contains("0x006cec7c+0x97"))
         );
         assert_eq!(
             trace

docs/rehost-queue.md

@@ -220,11 +220,12 @@ Working rule:
     per-entry vtable slot `+0x40`; current local recovery still only grounds that seam through the
     cached-source bridge `0x0040ce60 -> 0x0040cd70 / 0x0045c150`, not through a direct
     `[site+0x276]` republisher
-  - the grouped-opcode family is ruled down too:
+  - the grouped-opcode family is narrower rather than fully ruled down:
-    current direct caller census only reaches `0x00431b20` from scenario runtime-effect service
+    `0x00431b20` is still only reached through scenario runtime-effect service
-    `0x004323a0 -> 0x00432f40` through direct call `0x00432317`, so `0x0061039c` currently reads
+    `0x004323a0 -> 0x00432f40` via direct call `0x00432317`, but that service loop is itself
-    as a live runtime-effect application lane rather than the missing persisted restore owner for
+    called from world bring-up at `0x00444d92` with trigger kind `8` under shell-profile latch
-    `[site+0x276]`
+    `[0x006cec7c+0x97]`; so `0x0061039c` currently reads as a startup-time live runtime-effect
+    application lane rather than an ordinary tagged restore owner
   - the `[site+0x27a]` companion lane is grounded now too:
     it is a live signed scalar accumulator rather than a second owner-identity seam, with zero-init
     at `0x0042125d` and `0x0040f793`, accumulation at `0x0040dfec` and `0x00426ad8`, direct set on
@@ -233,9 +234,9 @@ Working rule:
     identify which non-transport persisted source family outside the currently bounded direct
     allocator/finalize/store families, the save-side `0x00413440` serializer, the load-side
     `0x00413280` cached-source bridge, the checked ordinary replay strip
-    `0x00444690 -> 0x004133b0 -> 0x0040ee10`, and the live runtime-effect dispatcher
+    `0x00444690 -> 0x004133b0 -> 0x0040ee10`, and the startup-time runtime-effect dispatcher lane
-    `0x00431b20` feeds the tuple or companion restore calls that are sufficient to repopulate
+    `0x00444d92 -> 0x00432f40(kind 8) -> 0x004323a0 -> 0x00431b20` feed the tuple or companion
-    `[site+0x276]` for shellless acquisition
+    restore calls that are sufficient to repopulate `[site+0x276]` for shellless acquisition
   - 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]`