Tighten Tier2 candidate source bounds

docs/rehost-queue.md

@@ -758,14 +758,24 @@ Working rule:
     The new root scan sharpens that boundary further. `runtime scan-candidate-table-headers
     rt3_wineprefix/drive_c/rt3/maps` shows `37` probe-bearing shipped maps and `4` skips, while
     the narrower `runtime scan-candidate-table-named-runs` command confirms that
-    `Louisiana.gmp` and `Dutchlantis.gmp` share the same split shape:
-    `Port00` as an isolated run at row `35`, `Port01..11` as one contiguous run at rows `45..55`,
-    `Warehouse00` isolated at row `43`, and `Warehouse01..11` contiguous at rows `56..66`.
-    Raw map-string presence is broader than that actual candidate-table seam too:
+    the shipped probe-bearing maps split into two stable `00`-row families rather than one:
+    `30` maps keep `Port00` / `Warehouse00` at rows `35` / `43`, while `7` maps move just those
+    two `00` rows earlier to `10` / `18`; the `Port01..11` and `Warehouse01..11` runs stay fixed
+    at `45..55` and `56..66` in all `37` probe-bearing maps. Trailer families split separately
+    too: `28` maps keep the numbered rows on trailer `0x00000001`, while `9` maps keep the same
+    row layout but zero those trailers. Raw map-string presence is broader than that actual
+    candidate-table seam too:
     `Port00` appears in all `41` shipped `.gmp` files, but `Central Pacific.gmp`, `Italy.gmp`,
     `Tex-Mex.gmp`, and `Texas Tea.gmp` do not expose the fixed candidate-table header at all. So
     the next Tier-2 source pass should target the `37` probe-bearing maps rather than the noisier
     full string-bearing map corpus.
+    The earlier `+0x173` writer census now trims several dead ends from that pass. Direct
+    inspection shows `0x00416ded` is only a collection-local row-id seed via `0x00518380` before
+    `0x00518900`; `0x004274d8` and `0x0042872d` are object-local rollover/allocator copies; and
+    `0x005b7a6f` is just a helper-side child allocation. The only candidate-family `+0x173` store
+    in this strip that still matters to Tier-2 is `0x00419559`, and it is simply the later clone
+    pass stamping the chosen seed-row id onto the new row. So the queue no longer needs another
+    generic `+0x173` writer sweep before returning to the actual bank-byte owner.
     The direct `+0xba/+0xbb` writer census is narrower now too. The obvious newly surfaced stores
     at `0x004ecd42/0x004ecdaa` and `0x004ed5d5/0x004ed625` are only shell-side portrait/string
     refresh helpers: they walk a separate id-keyed collection through `0x0053f830`, free and
@@ -782,6 +792,16 @@ Working rule:
     divergence frontier is narrower again: not generic direct stores into candidate rows, but the
     earlier seed or projection seam that first makes some source/live rows reach that clone path
     with nonzero bank bytes.
+    That owner chain is explicit now too: the stock candidate collection root `0x0062b268` is
+    constructed at `0x00438c8e -> 0x004131f0 -> 0x00412fb0 -> 0x004120b0`, and the adjacent
+    `.rdata` strings at `0x005c93f4..0x005c940e` prove that `0x00412fb0` is the
+    `Data\\BuildingTypes\\%1*.bca` / `%1*.bty` loader, not a map-side overlay reader. The
+    immediate follow-on call at `0x00438ca0 -> 0x00411d90` is a no-op, so there is no hidden
+    world-load mutation directly after the stock constructor. That narrows the next Tier-2 source
+    question again: either a later candidate-class serializer/import/export family such as
+    `0x00414500..0x00414b14` is still replaying non-stock bank bytes into live rows, or the
+    qualifying source rows already live in the stock `BuildingTypes` corpus and the remaining work
+    is to explain which rows the later clone path chooses.
     The clone-group lane is tighter now too. Candidate dword `[candidate+0x794]` is not a broader
     owner-state field written elsewhere; the current direct write set shows it is initialized to
     zero in `0x004120b0` and then assigned only in `0x00412d70` as the chosen seed-row index that