hand BuildingSystem the belts per call, as its siblings get them

The last system holding a piece of the world as a member. ConstructionSystem and
ProductionSystem take the transport layer as a tick argument; BuildingSystem kept
a BeltSystem& from construction, so the same object arrived two different ways
depending on which system you were reading.

Three methods need it -- deconstruct, cancelDeconstruction and rotateInPlace, all
of which register or unregister a belt tile -- and they now take it after the
state, in the argument order the other systems use. The constructor is down to
the config alone.

CombatSystemTest's fixture kept a BeltSystem only to pass it here, so that goes
too.

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

src/test/CombatSystemTest.cpp

@@ -2,7 +2,6 @@
 
 #include <random>
 
-#include "BeltSystem.h"
 #include "Building.h"
 #include "BuildingSystem.h"
 #include "FactoryState.h"
@@ -55,7 +54,6 @@ struct CombatFixture
     FactoryState state = makeFactoryState(cfg);
     std::mt19937 rng;
     EntityAdmin admin;
-    BeltSystem belts;
     ShipSystem ships;
     BuildingSystem buildings;
     CombatSystem combat;
@@ -63,9 +61,8 @@ struct CombatFixture
     explicit CombatFixture()
         : cfg(loadTestConfig())
         , rng(42)
-        , belts(cfg.world.beltSpeed_tps)
         , ships(cfg, admin)
-        , buildings(cfg, belts)
+        , buildings(cfg)
         , combat(cfg)
     {
     }