say where the factory's data lives, now that it has moved

The FactoryState migration finished some time ago -- every system that touches
the factory takes the state as an argument and holds none of it, and the const
surface has become free functions over the struct -- but the comments still
described the state of affairs two refactors back.

FactoryState.h claimed BuildingSystem holds a reference and that passing the
state into the tick methods was the remaining step, gated on ~180 const call
sites that no longer exist. It now says what is true, and names what genuinely
has not moved: the id counter and the block stock, factory data still living on
Simulation behind callbacks.

architecture.md described neither FactoryState nor FactoryQueries at all, so the
Buildings section told a reader that buildings are a plain vector and nothing
about who owns it or how it is read. It gains that section, including why
ConstructionSystem completes a building itself.

BuildingSystem.h had collected ten comment blocks whose declarations had moved
out from under them -- the whole Queries section was four comments and no
functions, and the deconstruction-queue tick comment sat above tickBeltPull,
documenting the wrong function. Those are gone; tickBeltPull gets a comment
describing what it actually does, and the Queries banner now points at where the
queries went. No code changed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x

docs/architecture.md

@@ -242,6 +242,44 @@ struct Building {
 - Belts and splitters are separate types owned by the belt subsystem, not general `Building` instances.
 - No ECS for buildings. A miner is never also an assembler; there is no composition benefit to decomposing buildings into components.
 
+### Factory State and Queries
+
+The buildings, the construction and deconstruction queues, and the tile-ownership grid
+live in one struct — `FactoryState` — owned by `Simulation` (and by `ArenaSimulation` in
+the balancing tool), never by a system. It is data with no behaviour of its own, the
+buildings-side counterpart to `EntityAdmin`.
+
+```cpp
+struct FactoryState {
+    std::vector<Building>           buildings;
+    std::deque<ConstructionSite>    constructionQueue;
+    std::deque<DeconstructionEntry> deconstructionQueue;
+    BuildingGrid                    grid;                    // who owns which tile
+    int                             asteroidWidth_tiles = 0; // left placement bound
+};
+```
+
+Every system that touches the factory — `BuildingSystem`, `ConstructionSystem`,
+`DeconstructionSystem` — takes it as an argument and holds none of it, the same shape the
+`lib/ecs/system` classes have, where the world arrives per tick. This is why
+`ConstructionSystem` can complete a building itself instead of handing the finished site
+back to `BuildingSystem`: with the state in the argument there is no owner to route
+through.
+
+**Reading the factory needs no system.** The queries are free functions over the state:
+`FactoryQueries.h` for what is where (`findBuilding`, `getInputPorts`, `collectBeltTiles`),
+`PlacementRules.h` for whether a placement is legal, `ProductionRules.h` for what a
+building could run and what its status light shows. A caller therefore depends on the data
+it reads rather than on whichever system happens to tick it — which is what let the UI, the
+balancing tool and the tests stop reaching through `BuildingSystem` for const answers.
+
+What has not moved yet: the building-id counter and the global building block stock are
+factory data that still live on `Simulation`, reached through callbacks
+(`m_allocateBuildingId`, `m_addBuildingBlocks`) held by `BuildingSystem` and
+`DeconstructionSystem`. `m_spawnShip` and `m_isItemUnlocked` are genuine cross-domain
+reaches — into the entity model and the unlock state — and are not candidates for this
+struct.
+
 ## Debris
 
 Debris — the salvageable object dropped by destroyed ships and defence stations — is the