Rule out base placed-structure load callback

crates/rrt-runtime/src/smp.rs

@@ -5600,6 +5600,9 @@ fn build_periodic_company_service_trace_report(
     notes.push(
         "One nearby live helper strip is narrower now too: 0x004337a0 is exactly the raw selected-company getter over [world+0x21], used in the replay-side sibling around 0x0040e775 only to compare the current selection against [site+0x276]. The adjacent world-side helpers 0x00452d80 / 0x00452db0 / 0x00452fa0 are separate live selected-site or active service-state setters/dispatchers over [world+0x217d/+0x2181] gated by mode byte [world+0x2175]; they can clear or republish currently-selected site ids through 0x00413620 / 0x00413750, but they do not repopulate [site+0x276] for already-restored rows.".to_string(),
     );
+    notes.push(
+        "The base placed-structure load callback is narrower now too: local .rdata at 0x005cb4c0 shows that the shared base table, not the 0x005c8c50 specialization table, owns the 0x0045c150 / 0x0045b560 / 0x00455870 / 0x00455930 load-save quartet. Direct disassembly of 0x0045c150 -> 0x00455fc0 then shows that callback only reloads the generic 0x55f1/0x55f2/0x55f3 triplet/scalar bands and re-enters the same base triplet/scalar slots 0x00455870 / 0x00455930, so the missing placed-structure owner-company lane [site+0x276] still lies outside the checked-in base load path.".to_string(),
+    );
     notes.push(
         "Direct disassembly now closes the negative persistence side too: the direct 0x36b1 per-record callbacks serialize the shared base scalar triplets rooted at [this+0x206/+0x20a/+0x20e] plus the subordinate payload callback strip, while the 0x4a9d/0x4a3a/0x4a3b side-buffer owner only persists route-entry lists, three byte arrays, five proximity buckets, and the sampled-cell list. That means neither checked-in save owner seam currently persists the core peer-site identity fields [site+0x04], [site+0x2a8], or [peer+0x08] directly.".to_string(),
     );

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

@@ -3712,6 +3712,13 @@ The low helper strip beneath that shared family is tighter now too: `0x0052ecd0`
   `[world+0x217d/+0x2181]` gated by mode byte `[world+0x2175]`; they can clear or republish
   currently-selected site ids through `0x00413620 / 0x00413750`, but they do not repopulate
   `[site+0x276]` for already-restored rows.
+  The base load callback underneath the same family is narrower now too. Local `.rdata` at
+  `0x005cb4c0` shows that the shared base table, not the `0x005c8c50` specialization table, owns
+  the `0x0045c150 / 0x0045b560 / 0x00455870 / 0x00455930` load-save quartet. Direct disassembly of
+  `0x0045c150 -> 0x00455fc0` then shows that callback only reloads the generic
+  `0x55f1/0x55f2/0x55f3` triplet/scalar bands and re-enters the same base triplet/scalar slots
+  `0x00455870 / 0x00455930`, so the missing placed-structure owner-company lane `[site+0x276]`
+  still lies outside the checked-in base load path.
   On the wider chooser question, the current evidence is also tighter than before: every recovered
   external owner of `0x00402cb0` is still in the city-connection family, so the two later direct
   placement lanes currently read as city-connection fallback behavior rather than a broadly shared

docs/rehost-queue.md

@@ -67,6 +67,12 @@ Working rule:
     world-side helpers `0x00452d80 / 0x00452db0 / 0x00452fa0` are live selected-site or active
     service-state setters/dispatchers over `[world+0x217d/+0x2181]` gated by mode byte
     `[world+0x2175]`, not restore-time republishers for `[site+0x276]`
+  - the base placed-structure load callback is narrower now too:
+    local `.rdata` at `0x005cb4c0` shows the shared base table, not the `0x005c8c50`
+    specialization table, owns the `0x0045c150 / 0x0045b560 / 0x00455870 / 0x00455930`
+    load-save quartet; direct disassembly of `0x0045c150 -> 0x00455fc0` shows that callback only
+    reloads the generic `0x55f1/0x55f2/0x55f3` triplet/scalar bands and then re-enters the base
+    triplet/scalar slots `0x00455870 / 0x00455930`, so it does not repopulate `[site+0x276]`
   - that makes the next linked-transit question narrower:
     identify which earlier restore or service owner feeds `[site+0x276]` and the live linked-peer
     rows before replay continuation `0x0040e360..0x0040edf6`, beyond the already-grounded