Ground acquisition cached candidate bridge

docs/rehost-queue.md

@@ -98,7 +98,23 @@ Working rule:
   - the same trace now also carries three explicit projection hypotheses for the next pass:
     - `site_owner_and_self_id_replay_from_post_load_refresh`
     - `site_cached_tri_lane_payload_or_restore_owner`
-    - `backing_record_selector_to_candidate_subtype_projection`
+    - `cached_source_candidate_id_to_subtype_projection`
+  - the first of those is now partly ruled down by the checked-in atlas:
+    `0x004133b0 -> 0x0040e450 / 0x0040ee10` rebuilds cloned local-runtime records and local
+    position/scalar triplets, but current evidence still does not tie that replay family directly
+    to `[site+0x276]` or `[site+0x2a4]`
+  - the second is narrower in the same way:
+    the checked-in `0x36b1/0x36b2/0x36b3` triplet seam and the
+    `0x4a9d/0x4a3a/0x4a3b` side-buffer seam still do not serialize `[site+0x310/+0x338/+0x360]`
+    directly, so the known save seams are ruled down even though a later restore family is still open
+  - the third hypothesis is now a cached source/candidate bridge question, not just a raw
+    `[site+0x04]` selector question:
+    `0x0040cd70` seeds `[site+0x3cc/+0x3d0]` from `0x62b2fc / 0x62b268`,
+    `0x0040cee0` resolves cached candidate id `[site+0x3d0]` back into the live candidate pool,
+    and `0x004138f0` already counts live placed structures by that cached candidate id
+  - that leaves the remaining subtype blocker narrower:
+    no checked-in replay or restore owner yet guarantees `[site+0x3d0]` is populated for the
+    acquisition-side rows before `0x0040d360` consumes candidate subtype byte `[candidate+0x32]`
   - 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