Split placed-structure writer families

crates/rrt-runtime/src/smp.rs

@@ -5603,6 +5603,9 @@ fn build_periodic_company_service_trace_report(
     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(
+        "The remaining direct [site+0x276] writers are split more cleanly now too: 0x00421200 is the broad late-field constructor/reset zero-fill over the same 0x23a/0x23e/0x25a/0x25e/... row family and clears [+0x276] as part of that initialization; 0x00428270 is a collection-wide live owner remap over 0x0062b26c that rewrites [site+0x276] only for rows matching one caller-supplied old owner id; and 0x00422280 is a subtype-local synthetic scalar writer that buckets float lane [row+0x25e], stores one 100000 * rand(bucket) result into [+0x276], and immediately publishes localized-id 7. Those writes therefore sit under constructor/live mutation or subtype-local scalar families, not the missing restore-time owner-company replay seam.".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

@@ -3719,6 +3719,15 @@ The low helper strip beneath that shared family is tighter now too: `0x0052ecd0`
   `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.
+  The remaining direct `[site+0x276]` writers are split more cleanly now too. `0x00421200` is the
+  broad late-field constructor/reset zero-fill over the same `0x23a/0x23e/0x25a/0x25e/...` row
+  family and clears `[+0x276]` as part of that initialization. `0x00428270` is a collection-wide
+  live owner remap over `0x0062b26c`, rewriting `[site+0x276]` only for rows that still match one
+  caller-supplied old owner id. `0x00422280` is narrower again: it buckets local float lane
+  `[row+0x25e]`, generates one `100000 * rand(bucket)` scalar, stores that into `[+0x276]`, and
+  immediately publishes localized-id `7`. Those three writes therefore belong to constructor/live
+  mutation or subtype-local scalar families, not the missing restore-time owner-company replay
+  seam.
   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

@@ -963,6 +963,13 @@ Working rule:
     `0x004269b0 / 0x00426a10`, the create-side `0x0040ef10 / 0x0040f6d0` strip, and the bulk
     reassignment families `0x00426dce..0x00426ea1` and `0x00430040..0x004300d6`, not under the
     known `0x00444690 -> 0x004133b0 -> 0x0040ee10` replay strip
+  - the direct writer census is split more cleanly now too:
+    `0x00421200` is the broad late-field constructor/reset zero-fill over the same
+    `0x23a/0x23e/0x25a/0x25e/...` row family and clears `[+0x276]` as part of that initialization,
+    `0x00428270` is a collection-wide live owner remap over `0x0062b26c` that rewrites
+    `[site+0x276]` only for rows matching one old owner id, and `0x00422280` is a subtype-local
+    synthetic scalar writer that stores one `100000 * rand(bucket)` result into `[+0x276]` before
+    publishing localized-id `7`, so none of those three writes is the missing replay owner seam
   - the same write side is now grounded one level higher too:
     direct local control-flow reconstruction shows those families hanging under the grouped opcode
     dispatcher `0x00431b20` over `0x0061039c`, with opcodes `0x04..0x07` dispatching to