Classify zero-family stock alias clusters

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

@@ -96,6 +96,12 @@
   `Distillery x2`, `Toolndie x2`). So the next load-side source-selection pass should bias toward
   that `0x5e` alias-root lane when testing why the later chooser seeds only part of the stock
   family into the numbered Tier-2 bank.
+  The same `name_0x5e` dword-family summary now also says the current residue is still stock-side:
+  `MunitionsFactory` belongs to a zero-valued `WeaponsFactory` alias cluster with
+  `Electric Plant`, `Fertilizer Factory`, `Nuclear Power Plant`, `Oil Well`, and `Weapons
+  Factory`. So the next load-side source-selection pass should treat the open question as one of
+  cluster choice inside the wider stock corpus, not as a jump from stock rows to some unrelated
+  non-stock family.
   The fixed
   tail is explicit now too: `0x00444dd0` writes one direct dword from
   `[world+0x19]`, one zeroed `0x1f4`-byte slab under `0x32cf`, closes the package, derives the

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

@@ -1339,6 +1339,14 @@
   stronger stock-family clue than the direct-name lanes, and keep the explicit non-overlap residue
   (`MunitionsFactory/MunitionsFactory x1`) separate instead of folding it into the recovered
   industrial/commercial subset.
+  That non-overlap residue is grounded against the wider stock corpus now too. The same checked-in
+  `name_0x5e` dword-family summary shows `MunitionsFactory` sits in a zero-valued
+  `WeaponsFactory` alias cluster (`Electric Plant`, `Fertilizer Factory`, `Munitions Factory`,
+  `Nuclear Power Plant`, `Oil Well`, `Weapons Factory`) rather than outside stock assets
+  entirely. So the remaining Tier-2 chooser/source-selection frontier is no longer “stock vs
+  non-stock”; it is which stock alias-root cluster is selected and why later clone/replay paths
+  prefer the nonzero `0x000001f4` cluster while the peer-site residue can still surface a
+  zero-family `WeaponsFactory`-side root.
   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

@@ -1285,6 +1285,15 @@ Working rule:
     chooser-side/source-selection slice can focus on whether that residue belongs to a zero-valued
     stock-header family or to a later live projection seam rather than treating the whole nonzero
     post-secondary set as one undifferentiated mystery
+  - that broader stock-header check is now grounded too: the checked-in `name_0x5e` dword-family
+    summary shows `MunitionsFactory` is not outside stock assets at all. It sits in a zero-valued
+    `WeaponsFactory` alias cluster (`Electric Plant`, `Fertilizer Factory`, `Munitions Factory`,
+    `Nuclear Power Plant`, `Oil Well`, `Weapons Factory`) while the recovered nonzero family keeps
+    its own `TextileMill`, `LumberMill`, `MeatPackingPlant`, `Distillery`, and `Toolndie`
+    clusters. So the next Tier-2 source-selection question is no longer “stock vs non-stock”; it
+    is which stock alias-root cluster gets selected, and why some later clone/replay paths prefer
+    the nonzero `0x000001f4` cluster while the peer-site residue can still surface a zero-family
+    `WeaponsFactory`-side root
   - keep the already-grounded `0x0047fd50` class gate separate from that byte: direct disassembly
     now says `0x0047fd50` resolves the linked peer through `[site+0x04]`, reads candidate class
     byte `[candidate+0x8c]`, and returns true only for `0/1/2` while rejecting `3/4` and above,