Align Tier2 source tables with stock assets

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

@@ -64,6 +64,17 @@
   `StationLrg`, `ServiceTower`, `Maintenance`, `ClpBrd`, `Kyoto`, `Persian`, `SoWest`, `Tudor`,
   and `Victorian`, so the remaining Tier-2 load-side question is the style-family row-selection
   path into that later bank pass rather than another hidden naming stage.
+  The shipped asset directory makes the bare-name remap boundary explicit too:
+  `Data/BuildingTypes` contains bare `Port.bty/.bca` and `Warehouse.bty/.bca`, but no stock
+  `Port00` or `Warehouse00` assets on disk, so the loader-side `port -> Port00` and
+  `warehouse -> Warehouse00` rewrite is the real stock bridge.
+  The stock asset corpus agrees with that table directly too: `Data/BuildingTypes` contains
+  `VictorianStationSml/Med/Lrg.bty`, `TudorStationSml/Med/Lrg.bty`,
+  `SoWestStationSml/Med/Lrg.bty`, `PersianStationSml/Med/Lrg.bty`,
+  `KyotoStationSml/Med/Lrg.bty`, `ClpBrdStationSml/Med/Lrg.bty`, plus standalone
+  `Maintenance.bty` and `ServiceTower.bty`, alongside the style-specific house families. So the
+  recovered `0x005f3c6c/0x005f3c80` naming strip is now backed by the shipped on-disk
+  `BuildingTypes` filename families, not only by the loader-side disassembly.
   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

@@ -1282,6 +1282,10 @@
   stay in `named_binding_comparison.binding_only_canonical_stems`. So the numbered Tier-2
   families no longer belong under stock `BuildingTypes/*.bty` discovery either; they belong under
   the scenario/live candidate-table projection seam above the now-grounded bare-name remap.
+  The shipped asset directory makes that remap boundary explicit too: `Data/BuildingTypes`
+  contains bare `Port.bty/.bca` and `Warehouse.bty/.bca`, but no stock `Port00` or
+  `Warehouse00` assets on disk. So the loader-side `port -> Port00` and `warehouse -> Warehouse00`
+  rewrite is the actual stock bridge, not a hidden numbered asset family.
   The stock source-family loader above that remap is bounded now too. `0x004196c0` walks the
   `%1*.bty` file set, routes each match through `0x00414490`, calls the stock load callback
   `0x00416ce0`, and only then tails into `0x00419230`. The currently recovered source-name set is
@@ -1289,6 +1293,13 @@
   `Persian`, `SoWest`, `Tudor`, and `Victorian`, so the remaining Tier-2 source frontier is the
   style-family row-selection path into the later banked clone pass, not another hidden name
   generator.
+  The shipped asset corpus agrees with that table directly too: `Data/BuildingTypes` contains
+  `VictorianStationSml/Med/Lrg.bty`, `TudorStationSml/Med/Lrg.bty`,
+  `SoWestStationSml/Med/Lrg.bty`, `PersianStationSml/Med/Lrg.bty`,
+  `KyotoStationSml/Med/Lrg.bty`, `ClpBrdStationSml/Med/Lrg.bty`, plus standalone
+  `Maintenance.bty` and `ServiceTower.bty`, alongside the style-specific house families. So the
+  `0x005f3c6c/0x005f3c80` pair now lines up with real stock filename families on disk rather than
+  only a disassembly-side naming hypothesis.
   The exact-match helper under that family is bounded now too. `0x00419590` copies one
   source-kind name from `0x005f3c6c`, combines it with one style/theme entry from the smaller
   subset table `0x005f3c80` through format `"%1%2"` at `0x005c8730`, and then scans the live

docs/rehost-queue.md

@@ -816,6 +816,11 @@ Working rule:
     stock `BuildingTypes/*.bty` discovery for the numbered families either; the remaining `01..11`
     source work belongs under scenario/live candidate-table projection and row-family choice above
     the already-grounded bare-name remap.
+    The shipped asset directory makes that remap boundary explicit too: `Data/BuildingTypes`
+    contains bare `Port.bty/.bca` and `Warehouse.bty/.bca`, but no stock `Port00` or
+    `Warehouse00` assets on disk. So the checked-in queue no longer needs to speculate about a
+    hidden on-disk `00` family; the loader-side `port -> Port00` and `warehouse -> Warehouse00`
+    rewrite is the actual stock bridge.
     The stock source-family strip above that remap is grounded now too. `0x004196c0` walks the
     `%1*.bty` file set, routes each match through `0x00414490`, calls the stock load callback
     `0x00416ce0`, and only then tails into `0x00419230`. The recovered source-name table is
@@ -823,6 +828,14 @@ Working rule:
     `Persian`, `SoWest`, `Tudor`, and `Victorian`, so the next Tier-2 source question is no longer
     “where do numbered names come from?” but “which style-family rows first survive into the later
     two-bank, twelve-ordinal clone pass?”
+    The stock asset corpus now agrees with that table directly too. The shipped
+    `Data/BuildingTypes` directory contains `VictorianStationSml/Med/Lrg.bty`,
+    `TudorStationSml/Med/Lrg.bty`, `SoWestStationSml/Med/Lrg.bty`,
+    `PersianStationSml/Med/Lrg.bty`, `KyotoStationSml/Med/Lrg.bty`,
+    `ClpBrdStationSml/Med/Lrg.bty`, plus standalone `Maintenance.bty` and
+    `ServiceTower.bty`, alongside the style-specific house families. So the
+    `0x005f3c6c/0x005f3c80` tables are no longer just a recovered naming hypothesis; they line up
+    with real stock filename families on disk.
     The exact-match resolver beneath that style-family strip is grounded now too. `0x00419590`
     copies one source-kind name from `0x005f3c6c`, combines it with one style/theme entry from the
     smaller subset table `0x005f3c80` through format `"%1%2"` at `0x005c8730`, and then scans the