Ground placed-structure replay owner flow

docs/rehost-queue.md

@@ -50,25 +50,30 @@ Working rule:
   - `0x0047dda0` consumes `[peer+0x08]` as the linked route-entry anchor id
   - `0x00480710 -> 0x0048abc0 / 0x00493cf0` is the linked-site refresh and route-entry rebind or
     synthesis strip above that anchor lane
+  - late world bring-up `0x00444690` is the current caller of
+    `0x004133b0 placed_structure_collection_refresh_local_runtime_records_and_position_scalars`
+  - `0x004133b0` drains queued site ids through `0x0040e450` and then sweeps all live sites
+    through `0x0040ee10`
+  - `0x0040ee10` reaches `0x0040edf6 -> 0x00480710` for linked-peer refresh and then the later
+    `0x0040e360` follow-on
+  - `0x004160aa` is a separate non-bring-up runtime caller of `0x0040ee10`
   - the direct `0x36b1` per-record callbacks serialize base scalar triplets
     `[this+0x206/+0x20a/+0x20e]` plus the subordinate payload callback strip, and the
     `0x4a9d/0x4a3a/0x4a3b` side-buffer owner only persists route-entry lists, three byte arrays,
     five proximity buckets, and the sampled-cell list
   - the winning linked company id comes from `[region+0x2a4]`
-  So the next owner question is no longer “what does the acquisition branch do?” but “which
-  post-load owner replays the subtype-`1` constructor or linked-site refresh paths for existing
-  saves once those two save-owner seams finish?”
+  So the next owner question is no longer “what does the acquisition branch do?” or “which post-
+  load owner replays linked-site refresh?” but “which remaining owner reseeds the live backing-
+  record selector `[site+0x04]` once the existing bring-up replay finishes?”
 - Make the next static/rehost slice the peer-site rebuild seam above persistence, not another save
   scan:
-  - find which post-load non-hook owner actually replays
-    `0x0040f6d0 -> 0x00481390 -> 0x00480210` for existing saves, now that the concrete writes to
-    `[peer+0x04]` and `[site+0x2a8]` are grounded
-  - bound how far the concrete side-refresh callers
-    `0x0040df27 / 0x0040e00a / 0x0040edf6 -> 0x00480710 -> 0x0048abc0 / 0x00493cf0`
-    refresh or synthesize `[peer+0x08]` after load
-  - find the first upstream post-load owner that reseeds `[site+0x04]` before
+  - treat `0x00444690 -> 0x004133b0 -> 0x0040e450 / 0x0040ee10 -> 0x0040edf6 -> 0x00480710` as
+    the checked-in bring-up replay path for existing saves
+  - treat `0x004160aa -> 0x0040ee10` as the checked-in recurring runtime maintenance entry into the
+    same linked-peer refresh strip
+  - find the remaining owner that reseeds `[site+0x04]` before
     `0x00420030 / 0x00420280 / 0x0047efe0 / 0x0047fd50` consume it, if that owner is distinct
-    from the constructor replay path
+    from the bring-up replay path
 - Use the higher-layer probes as the standard entry point for the current blocked frontier instead
   of generic save scans:
   `runtime inspect-periodic-company-service-trace <save.gms>`,