Sharpen fleet handling, widen the laser, and fix the map editor's file identity

The fleet had a second of inertia in it: every vessel's acceleration sat at
roughly its own top speed, so flipping the stick while cruising took 0.58s to
take effect and let go coasted 222 units, while the formation anchor the ships
chase turns instantly. Acceleration is now ~3x top speed, chosen by measuring
rather than taste - past 3x the reversal time stops improving because
max_speed becomes the limit. Measured after: 0.18s and 23 units.
test_fleet_agility guards all three numbers and proves the bounds discriminate
by re-running the same measurement at the old value.

The laser reaches 1450 instead of 950 and strikes 38 units either side instead
of 22. Its drawn width is now derived from the hit width: the two were
independent numbers that had drifted, so the beam killed things it visibly
missed. LaserController's aim range also stopped hardcoding a second copy of
950. Tapping the laser button without dragging used to do nothing at all - the
press was claimed, the aim begun, then thrown away on release. It now fires at
the nearest enemy in range; dragging still aims precisely. That lives in the
shared aimed-ability controller, so the gas bomb gains it too.

Planets sat one per ~29 chunks - some 35,000 units of nothing between them.
Now one per ~12, measured over 14,641 chunks. The two thresholds moved by
different amounts deliberately: every SPACE-biome planet is a gas giant, so
lowering both equally would have tripled the gas-giant share as well. This
changes how often you find a planet, not what you find. Extractors produce
half as fast to match, so expanding is what grows the economy.

The research screen gave its tree 386px of 1280 and the text below it 520.
The text is now at the bottom, the tree has 550, and the resource table has
room and legible type - and its LOCAL column is no longer hidden behind the
close button.

Two map-editor bugs turned out to be one cause: a setup's id and its FILENAME
are not the same thing, and both save and delete rebuilt the path from the id.
ResearchLabSetup.tres holds setup_id "research_lab_1", so deleting it looked
for a file that does not exist and silently refused - which read as "the first
item in the list cannot be deleted" - while saving it wrote a second file
under the derived name and left the original behind, so the pool served the
stale twin. A third bug hid behind those: rescan() re-read through Godot's
resource cache and handed back pre-save values even when the file on disk was
correct. All three present to a player as "my change was not saved".

Research labs no longer grant a point of their own; what conquering one is
worth comes entirely from its authored map, as asked. The shipped lab map
carries 1 so the balance is unchanged - only where it is configured moved.

Suite 109/109. Four tests changed because the behaviour they pinned changed:
the joystick coast is now derived from cruise_speed^2/(2*acceleration) rather
than a constant tuned to one acceleration; the extractor wait derives from
EXTRACTOR_RATE; the research-point test asserts the delegation; and the black
hole test no longer assumes nobody will ever author a void-profile map.
test_planet_setups and test_planet_map_assignment stopped depending on which
maps happen to be in the content folder, which was making them fail when maps
were added or deleted elsewhere.

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

PlanetSetups.gd

@@ -31,7 +31,19 @@ static func _ensure_scanned() -> void:
 	var file_name: String = dir.get_next()
 	while file_name != "":
 		if not dir.current_is_dir() and file_name.ends_with(".tres"):
-			var res: Resource = load(SETUPS_DIR + "/" + file_name)
+			# CACHE_MODE_REPLACE, not a plain load(). Godot caches resources by
+			# path, so after the map editor saved a setup this handed back the
+			# CACHED copy - still holding the values from before the save. The
+			# editor called rescan() and the pool dutifully re-served the stale
+			# data, which is what "I changed the research points and it was not
+			# saved" actually was: the file on disk was correct all along.
+			#
+			# REPLACE rather than IGNORE deliberately: it refreshes the
+			# existing instance in place instead of minting a new one, so
+			# object identity across a rescan survives - which the per-planet
+			# map assignments depend on (see setup_for_planet).
+			var res: Resource = ResourceLoader.load(SETUPS_DIR + "/" + file_name,
+				"", ResourceLoader.CACHE_MODE_REPLACE)
 			if res != null and res.get_script() == PLANET_SETUP_SCRIPT:
 				_all.append(res)
 		file_name = dir.get_next()
@@ -62,6 +74,30 @@ static func all() -> Array:
 	return _all
 
 
+static func find_by_id(setup_id: String) -> Resource:
+	for setup in all():
+		if String(setup.setup_id) == setup_id:
+			return setup
+	return null
+
+
+static func path_for_id(setup_id: String) -> String:
+	# The file a setup actually LIVES in, which is not reliably
+	# "PlanetSetups/<setup_id>.tres". Authored resources carry whatever
+	# filename they were created with, and at least one shipped setup has an
+	# id that differs from its filename outright (ResearchLabSetup.tres holds
+	# setup_id "research_lab_1"). Deriving the path from the id instead of
+	# asking the resource broke two things at once: deleting such a setup
+	# looked for a file that does not exist and silently refused, and saving
+	# one wrote a SECOND file under the derived name, leaving the original
+	# behind with the old contents - which reads exactly like "my change was
+	# not saved", because the stale twin is still in the pool.
+	var setup: Resource = find_by_id(setup_id)
+	if setup != null and String(setup.resource_path) != "":
+		return String(setup.resource_path)
+	return "%s/%s.tres" % [SETUPS_DIR, setup_id]
+
+
 static func setups_for_profile(profile_id: String) -> Array:
 	var result: Array = []
 	for setup in all():