Bound linked-transit selected-site helper strip

crates/rrt-runtime/src/smp.rs

@@ -5597,6 +5597,9 @@ fn build_periodic_company_service_trace_report(
     notes.push(
         "The per-company cache-cell layout is bounded now too: 0x004093d0 and 0x00407bd0 use bytes +0x00/+0x01 as the initial participation gates, dword +0x02 as the peer-row count, dword +0x06 as the peer-row pointer, dword +0x0a as the shorter peer-cache refresh stamp, and floats +0x0e/+0x12/+0x16 as the weighted/raw/final linked-transit score lanes. The candidate-table and route-entry-tracker owners are bounded above that too: 0x0062ba8c is constructed through 0x0041f4e0 -> 0x0041ede0 -> 0x0041e970, while 0x004a6360 / 0x004a6630 sit under owner-notify refresh 0x00494fb0. The remaining linked-transit gap is narrower again: subtype-4 follow-on 0x0040eba0 already republishes [site+0x2a4] through 0x004814c0 / 0x00481480 and world-cell chain helpers 0x0042c9f0 / 0x0042c9a0, and direct inspection of 0x0040ea96..0x0040eb65 shows that owner-company branch only consumes [site+0x276] rather than rehydrating it. That pushes the open question one level earlier to whichever restore or service owner feeds [site+0x276] and the live linked-peer rows before this replay continuation runs.".to_string(),
     );
+    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(
         "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

@@ -3704,6 +3704,14 @@ The low helper strip beneath that shared family is tighter now too: `0x0052ecd0`
   `0x00409720`, strips route lists from company-owned trains in modes `0x0a/0x13`, and then
   re-enters `train_try_append_linked_transit_autoroute_entry` `0x00409770` only when a train's
   route list has become empty.
+  One nearby live helper strip is narrower now too. Direct inspection of the replay-side sibling
+  around `0x0040e775` shows `0x004337a0` is exactly the raw selected-company getter over
+  `[world+0x21]`, used there only to compare the current selection against placed-structure lane
+  `[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.
   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

@@ -62,6 +62,11 @@ Working rule:
   - the owner-company branch is tighter now too:
     direct inspection of `0x0040ea96..0x0040eb65` shows that it consumes `[site+0x276]` and
     branches through owner/company helpers, but does not itself rehydrate `[site+0x276]`
+  - the nearby selected-company and live-site helper strip is tighter now too:
+    `0x004337a0` is the raw selected-company getter over `[world+0x21]`, and the adjacent
+    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]`
   - 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