number the buildings from the factory that holds them

The building-id counter was the last piece of factory data living on Simulation
behind a callback: every construction site, every building, and every tile a
station entity claims took its id from a std::function BuildingSystem held, which
the arena and three test fixtures each had to supply.

It moves into FactoryState as nextBuildingId, handed out by
allocateBuildingId(state) in FactoryQueries beside the other operations over the
state. BuildingSystem's callback is gone; so are Simulation::allocateBuildingId
and ArenaSimulation::allocateBuildingId, whose remaining callers now allocate
from the state directly.

Checksum order is untouched: Simulation folds the counter where it always did.

What is left on BuildingSystem is the config, the belts, the RNG, and two
callbacks that reach genuinely outside the factory -- spawning a finished ship
into the entity model, and testing an output group against the unlock state.
Neither is factory data, so this is where the migration stops.

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

src/lib/sim/FactoryState.h

@@ -58,6 +58,12 @@ struct FactoryState
     // Seeded from config by BuildingSystem's constructor.
     int                             asteroidWidth_tiles = 0;
 
+    // Next id to hand out for a building, a construction site, or a tile claimed by a
+    // station entity. Strictly increasing and never reused, so an id names one thing for
+    // the whole run -- which is what lets a command reference a building across a replay
+    // (docs/replay_design.md). Allocated through allocateBuildingId (FactoryQueries.h).
+    BuildingId                      nextBuildingId = 1;
+
     // The global building block stock (REQ-HQ-STARTING-BLOCKS, REQ-HQ-BELT-INPUT):
     // what placement spends, what deconstruction refunds, and what blocks delivered to
     // the HQ add to. Factory data, so it lives with the factory rather than being