Bound individual vessel speed; stop Fleet.stop() accumulating it (#72)

Rotating the fleet and spamming a direction let vessels fall out of sync
and fly at wildly high speeds. The pivot cooldown added earlier throttled
how often the exploit could be triggered; it never touched the cause.

Fleet.stop() did `ship.velocity = ship.velocity + ship.fleet_velocity`,
compensating for the fact that Ship.velocity read zero during cruise. The
next steer refilled fleet_velocity, so every press-release cycle added a
whole cruise velocity to the ship's own, decaying only at `acceleration` in
between. Tapping faster than that bled it off stacked them without limit,
and ships desynced because each bled off at a rate set by its own distance
to its slot. Measured before this change: spamming a direction while
pivoting flew the fleet 32737 units in 3s against 784 for simply holding
the stick, with a vessel reaching 48x its own top speed.

The compensation existed because `velocity` was not the ship's real motion:
Ship snapped to its slot every tick and zeroed it, so the truth lived in a
second field and anything wanting it had to add the two together. Fixed at
that root rather than by clamping the symptom:

- fleet_velocity is now fed FORWARD into the steering instead of carried
  alongside it. The ship aims to travel at its slot's velocity plus a
  correction closing the gap, so holding formation costs no error and
  `velocity` is always true world motion.
- The snap only applies when the slot is standing still, which is the one
  case where converging asymptotically would leave a residue. While the
  slot moves the ship steers continuously - a snap there was the teleport
  that made `velocity` lie in the first place.
- A hard bound on the INTEGRATED result every tick, not merely on the
  request, so no sequence of commands can leave a vessel over its own top
  speed.
- Fleet.stop() injects nothing; it reports that the slot has halted.

tests/test_fleet_speed_bounded.gd covers it, and fails against the previous
code with the numbers above: no vessel exceeds its own top speed however
hard the direction is spammed, spamming cannot cover more ground than
holding the stick, both hold while the formation is pivoting, and the fleet
stays together.

test_space_time_distorder.gd now clears the asteroid and enemy groups at
setup, the same clean-slate idiom test_ship_lab.gd uses. Silencing the
spawners was never enough - what Main.tscn had already placed kept moving,
and losing the distorder vessel to a rock resets the multiplier correctly,
which the test then reported three stages later as a failed scene swap. It
also checks it still crews a distorder vessel before relying on that.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Fleet.gd

@@ -238,33 +238,25 @@ func stop() -> void:
 	# since that lands inside arrive_radius immediately).
 	fleet_target = get_formation_origin()
 	for ship in ships:
-		# A ship's own `velocity` is NOT how fast it is really travelling
-		# while the fleet cruises. Ship snaps to its slot and reports zero
-		# the moment it is within arrive_radius of it, even though the
-		# anchor is dragging that slot forward at cruise_speed underneath
-		# it. Its true motion is its catch-up velocity PLUS the fleet's,
-		# which it already carries as `fleet_velocity` (zero for a
-		# point-to-point move_to, where `velocity` alone is the whole
-		# story).
+		# A ship's `velocity` is already its true motion, including the
+		# fleet's travel, because Ship feeds the slot velocity forward into
+		# its own steering rather than carrying it in a separate field. So
+		# stopping is only a matter of telling it the slot has halted and
+		# aiming it at the point its own braking curve reaches.
 		#
-		# Braking from `velocity` alone therefore stopped the fleet dead
-		# on any frame where the ships happened to be seated - and how
-		# often that happens depends on the frame rate, because the anchor
-		# advances cruise_speed * delta per frame. At ~25fps it steps far
-		# enough that ships always lag and always report motion, which is
-		# the only reason releasing the stick looked right.
-		var motion: Vector2 = ship.velocity + ship.fleet_velocity
-		# HAND THE FLEET'S MOTION TO THE SHIP. Until now the anchor was
-		# carrying it along and its own `velocity` was ~0, so aiming it at a
-		# braking point ahead made it start from REST: the fleet stopped
-		# dead, then accelerated into its own stopping distance and halted a
-		# second time. That is the "pause, then it moves again" stutter.
-		# Giving it the velocity it was actually travelling at makes the
-		# stop one continuous decelerating coast.
-		ship.velocity = motion
-		# Context that is no longer true: the fleet is not cruising any
-		# more, so leaving it set would have Ship face a heading it is not
-		# travelling on.
+		# This used to do `ship.velocity += ship.fleet_velocity` here, to
+		# compensate for `velocity` reading zero while the ship was in fact
+		# cruising (Ship snapped to its slot every tick and zeroed it). That
+		# compensation was an unbounded ACCUMULATOR: every release added a
+		# whole cruise velocity, the next steer refilled fleet_velocity, and
+		# tapping a direction repeatedly stacked them up faster than
+		# `acceleration` could bleed them off - so a vessel could be flung
+		# along at many times its own top speed, and ships fell out of sync
+		# because each bled off at a rate set by its own distance to its
+		# slot. Ship now bounds its total speed every tick as well, so
+		# neither half of that can come back.
+		var motion: Vector2 = ship.velocity
+		# The fleet is not cruising any more, so the slot is standing still.
 		ship.fleet_velocity = Vector2.ZERO
 		var speed: float = motion.length()
 		if speed <= 0.001: