Correct Tier2 stock selector corpus exception

docs/control-loop-atlas/runtime-roots-camera-and-support-families.md

@@ -1214,7 +1214,7 @@
   `[candidate+0xba/+0xbb]` are both zero. The later bring-up caller `0x00444acc` only re-enters
   that same `0x00437737 -> 0x00434f20 -> 0x00412c10` strip. So these startup passes still consume
   already-materialized bank/template bytes instead of explaining how live candidates diverge from
-  the all-zero shipped `BuildingTypes/*.bca` corpus before the later `Port%02d` /
+  the nearly-all-zero shipped `BuildingTypes/*.bca` corpus before the later `Port%02d` /
   `Warehouse%02d` rebuild.
   The constructor/import strip is fixed in the same negative way now too: `0x00438c70` allocates
   the live candidate pool through `0x004131f0`, calls `0x004411d90` (currently a no-op stub), and
@@ -1224,7 +1224,11 @@
   `0x005c93f0/0x005c9400` proves that strip is the stock `"%1*.bca"` scan under
   `".\\Data\\BuildingTypes\\"`. So the remaining bank-byte divergence is not hidden inside a
   second caller of the BCA parser; it has to happen after the fixed stock `BuildingTypes/*.bca`
-  import has already run, or through some later non-stock projection seam above it.
+  import has already run, or through some later non-stock projection seam above it. The stock
+  asset-side negative is no longer perfectly uniform either: the checked-in source report shows
+  every current shipped `.bca` stays zero at `0xb8..0xbb` except `MachineShop.bca`, which carries
+  the lone selector-window exception `(0x00, 0x80, 0x3f, 0x00)` on a `788`-byte row, while the
+  separate `backup/Bldg/*.bca` corpus stays fully zero there.
   The direct `+0xba/+0xbb` writer census now rules out a broad false lead too. The obvious new
   stores at `0x004ecd42/0x004ecdaa` and `0x004ed5d5/0x004ed625` are only shell-side
   portrait/string refresh helpers over a different id-keyed collection rooted through

docs/rehost-queue.md

@@ -732,6 +732,13 @@ Working rule:
     package path. So the remaining Tier-2 mystery is not “which hidden caller invokes the BCA
     parser?”; it is “which later non-stock writer or projection seam makes live
     `[candidate+0xba/+0xbb]` diverge after the fixed stock BCA import has already run?”
+    The stock asset-side negative is no longer completely uniform either. The checked-in
+    `inspect-building-type-sources` report now shows the shipped `Data/BuildingTypes` corpus is
+    zero at `0xb8..0xbb` for every current `.bca` except `MachineShop.bca`, which carries the lone
+    selector-window exception `(0x00, 0x80, 0x3f, 0x00)` on a `788`-byte row. The separate
+    `backup/Bldg/*.bca` corpus stays fully zero in that same window. So the queue head is narrower
+    again: explain whether the Machine Shop exception is part of the seeded Tier-2 family at all,
+    or recover the later projection seam that still has to account for the broader live divergence.
     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
@@ -759,8 +766,8 @@ Working rule:
     first seeded rows that let `0x00412d70` propagate nonzero bank bytes within that family?”
     So the honest next queue head is now one step earlier again:
     recover the non-stock writer or restore-time projection owner that makes some live candidates
-    reach those later consumer strips with nonzero `[candidate+0xba/+0xbb]` despite the observed
-    all-zero `BuildingTypes/*.bca` corpus.
+    reach those later consumer strips with nonzero `[candidate+0xba/+0xbb]` beyond the lone
+    `MachineShop.bca` selector-window exception in the shipped `BuildingTypes/*.bca` corpus.
     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: