Expose building source selector bytes

docs/rehost-queue.md

@@ -678,12 +678,15 @@ Working rule:
   - the writer-side split is narrower now too:
     direct disassembly of `0x004120b0` shows that the per-record stream-load helper clears
     `[candidate+0x79c/+0x7a0/+0x78c/+0x790/+0x794/+0x7b0]`, restores the fixed fields through
-    `[candidate+0x33]`, and streams the packed `0xbc` descriptor array into `[candidate+0x37]`,
-    but does **not** write `[candidate+0xba/+0xbb]` in the checked body. So the next concrete
-    recovery target is now the bank-qualified template source in `0x00412d70`, not the lower
-    tagged-record reader:
-    recover how preserved `[candidate+0xba/+0xbb]` bank/template state feeds the
-    `Warehouse%02d` runtime side before `0x00411ee0 / 0x00411ce0 / 0x00412c10` run.
+    `[candidate+0x33]`, restores `[candidate+0xb9/+0xba/+0xbb]`, and streams the packed `0xbc`
+    descriptor array into `[candidate+0x37]`. Direct disassembly of upstream source-record import
+    `0x00414490` also restores `[record+0xb8/+0xb9/+0xba/+0xbb]`. The new checked-in building
+    source inspector now shows the stock `Data/BuildingTypes/*.bca` corpus keeps those four bytes
+    zero across every observed file, including `Warehouse.bca` and `Port.bca`. So the next
+    concrete recovery target is no longer the lower tagged-record reader itself:
+    recover which later owner or alternate content path makes the live
+    `[candidate+0xba/+0xbb]` bank/template state diverge from that all-zero shipped BCA corpus
+    before `0x00411ee0 / 0x00411ce0 / 0x00412c10` run.
     kinds”; it is the smaller set of scenario-specific records where that sweep explicitly writes
     `[event+0x7ef]` itself or a still-later owner does.
   - two explicit trigger-kind materializations are now grounded inside that retagger: