Bind acquisition tri-lane to live scorer writers

docs/rehost-queue.md

@@ -115,7 +115,7 @@ Working rule:
     `0x00481430 -> 0x0047d8e0` repopulates the route-entry list, three byte arrays, five
     proximity buckets, and the trailing scratch band from stream, but still does not claim the
     cached tri-lane
-  - the tri-lane now has one real runtime consumer too:
+  - the tri-lane now has one real runtime accumulator too:
     direct local binary inspection shows `0x0040c9a0` folding `[site+0x310/+0x338/+0x360]` into
     `[site+0x2b4/+0x2b8/+0x2bc]`, mirroring the nine-dword side array rooted at `[site+0x2e4]`,
     and then clearing the tri-lane
@@ -123,6 +123,20 @@ Working rule:
     `0x0040c9a0` only appears under the broad live-collection sweep
     `0x0040a3a1..0x0040a4d3`, while `0x0040cac0` stays under weighted scoring or evaluation
     families such as `0x0040fcc0..0x0040fe28` and `0x00422c62..0x00422d3c`
+  - direct local binary inspection now rules out the old “no live writer” hypothesis too:
+    `0x0040d4aa/0x0040d4b0` add into `[site+0x310]`,
+    `0x0041114a7/0x004111572` add into `[site+0x310]`,
+    `0x0041114b7/0x004111582` add into `[site+0x338]`, and
+    `0x0041118aa/0x0041118f4` add into `[site+0x360]`
+  - the writer family is now bounded one level higher:
+    `0x0040d450` is a small owner-company-aware producer over `[site+0x276]`,
+    `0x00455810/0x00455800/0x0044ad60`, and `0x00436590` ids `0x66/0x68`, while
+    `0x00410b30..0x004118f4` is a broader candidate-processing loop walking `0xbc`-stride rows,
+    gating them through `0x00412560`, and then accumulating both stack temporaries and direct
+    writes into `[site+0x310/+0x338/+0x360]`
+  - `0x00412560` is now bounded as the shared candidate/admissibility gate above that loop:
+    it checks candidate-row fields `+0x20/+0x22/+0x24/+0x28/+0x2c/+0x44`, world date/flags via
+    `0x006cec78`, and the candidate table `0x0062ba8c`
   - the cached source/candidate bridge is now grounded on stream load too:
     direct local binary inspection shows `0x00413280` dispatching per-entry vtable slot `+0x40`
     on the `0x005c8c50` specialization table, that slot resolving to `0x0040ce60`, and
@@ -163,9 +177,11 @@ Working rule:
     `0x00402cb0 -> 0x00403ed5/0x0040446b -> 0x004134d0 -> 0x0040ef10`
     as the shared constructor/finalize strip for newly created site rows
   - so the acquisition blocker is no longer “is there any real consumer family above these
-    lanes?”, “how do new placed structures finalize?”, or “is `[site+0x2a4]` still missing?”; it
-    is specifically the restore or replay owner that populates `[site+0x276]` plus the cached
-    tri-lane for already-restored rows before shellless acquisition runs
+    lanes?”, “how do new placed structures finalize?”, “is `[site+0x2a4]` still missing?”, or
+    “does the tri-lane even have live writers?”; it is now specifically the persisted inputs and
+    exact shellless service semantics above the grounded live tri-lane scorer family, plus the
+    save-native or replay owner that populates `[site+0x276]` for already-restored rows before
+    shellless acquisition runs
   - direct disassembly now shows the generic base constructor `0x0052edf0` clearing base state
     through `0x0052ecd0` and then writing `[this+0x04]` from caller arg `1`
   - `0x00455b70` is the concrete placed-structure specialization constructor feeding