Classify machine shop Tier-2 selector outlier

docs/control-loop-atlas/map-and-scenario-content-load.md

@@ -108,6 +108,14 @@
   `MachineShop` inside the `TextileMill` cluster (`byte_0xba = 0x3f`, `byte_0xbb = 0x00`). So the
   next load-side source-selection pass should focus on that row-level outlier and any matching
   replay/seed logic, not on a whole-cluster nonzero bank hypothesis.
+  The direct-name plus alias plus selector join sharpens that one more step: inside the same
+  nonzero `0x000001f4` family, the direct `Warehouse/TextileMill/Warehouse` shape splits into six
+  all-zero selector peers (`ConcretePlant`, `ConstructionFirm`, `ElectronicsPlant`, `Hospital`,
+  `PharmaceuticalPlant`, and `Warehouse`) plus one unique selector outlier,
+  `MachineShop = 0x00/0x80/0x3f/0x00`. The sibling bare `Port/TextileMill/Port` row stays
+  all-zero. So the remaining load-side question is no longer whether the bare `Port` / `Warehouse`
+  row carries the stock exception; it is why one warehouse-shaped industrial peer in that same
+  alias family carries the lone selector while the bare rows do not.
   The global stock selector report tightens that further: the full `MachineShop.bca` signature
   (`0x00/0x80/0x3f/0x00` across `0xb8..0xbb`) is unique across the checked-in stock `.bca`
   corpus. So the remaining load-side Tier-2 frontier is one surfaced stock-file outlier plus the

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

@@ -1356,6 +1356,14 @@
   longer ask whether whole alias clusters map to nonzero bank bytes; it should ask why one
   specific stock row inside the `TextileMill` cluster surfaces a nonzero selector while its peer
   rows stay zero.
+  The direct-name plus alias plus selector join narrows that one step further. Inside the same
+  nonzero `0x000001f4` family, the direct `Warehouse/TextileMill/Warehouse` shape splits into six
+  all-zero selector peers (`ConcretePlant`, `ConstructionFirm`, `ElectronicsPlant`, `Hospital`,
+  `PharmaceuticalPlant`, and `Warehouse`) plus one unique selector outlier,
+  `MachineShop = 0x00/0x80/0x3f/0x00`. The sibling bare `Port/TextileMill/Port` row stays
+  all-zero. So the remaining Tier-2 source question is no longer whether the bare `Port` or
+  `Warehouse` row carries the seeded selector; it is why one warehouse-shaped industrial peer in
+  that alias family carries the lone seeded selector while the bare rows do not.
   The global stock `.bca` selector report narrows that again: the exact `MachineShop.bca`
   signature (`byte_0xb8 = 0x00`, `byte_0xb9 = 0x80`, `byte_0xba = 0x3f`, `byte_0xbb = 0x00`) is
   unique across the checked-in stock corpus. So the remaining Tier-2 source frontier is not a

docs/rehost-queue.md

@@ -1314,6 +1314,15 @@ Working rule:
     So the next Tier-2 source-selection pass should no longer ask whether whole alias clusters map
     to nonzero bank bytes; it should ask why one specific stock row inside the `TextileMill`
     cluster surfaces a nonzero selector while its peer rows stay zero
+  - the direct-name plus alias plus selector join narrows that one step further:
+    inside the same nonzero `0x000001f4` family, the direct
+    `Warehouse/TextileMill/Warehouse` shape splits into six all-zero selector peers
+    (`ConcretePlant`, `ConstructionFirm`, `ElectronicsPlant`, `Hospital`,
+    `PharmaceuticalPlant`, and `Warehouse`) plus one unique selector outlier,
+    `MachineShop = 0x00/0x80/0x3f/0x00`. The sibling bare `Port/TextileMill/Port` row stays
+    all-zero. So the remaining Tier-2 question is no longer “does the bare `Port` or
+    `Warehouse` row carry the seeded selector?”; it is “why does one warehouse-shaped industrial
+    peer in that alias family carry the lone seeded selector while the bare rows do not?”
   - the global stock `.bca` selector report narrows that one step further still: the exact
     `MachineShop.bca` signature (`byte_0xb8 = 0x00`, `byte_0xb9 = 0x80`, `byte_0xba = 0x3f`,
     `byte_0xbb = 0x00`) is unique across the checked-in stock corpus. So the current Tier-2