feat(input): full controller support, rebindable controls, and rotation fixes

Playing with a gamepad did not work: all six move_* actions had no joypad
event at all, so a pad could yaw/pitch/roll/turbo but could not translate.
Nothing caught it because every action existed and the game booted fine —
no assertion checked that an action is reachable on *both* devices.

Controller layout, on the 6DOF convention (left stick aims, right stick
translates), using all six of the pad's analog axes for the ship's six
degrees of freedom:

  left stick   yaw + pitch        right stick  strafe + vertical
  LB / RB      roll               RT / LT      forward / back
  L3           turbo              R3           ball camera

Input is now read with Input.get_axis instead of is_action_pressed, so
triggers and sticks are proportional. Keyboard values are unchanged.

Three rotation bugs found by measuring a real Ship rather than reading the
code:

- apply_torque() is world-space and the torque was never rotated into the
  hull's frame (unlike thrust, which uses -ship_basis.z). Roll input became
  pitch after a 90 degree turn and inverted at 180, so the controls were
  correct flying up-field and backwards flying back.
- ship.tscn's inertia is Vector3(7, 1, 7) but a flat torque was applied to
  every axis, giving yaw 7x the angular acceleration of pitch and roll
  (172 deg/s vs 52). Torque is now scaled per-axis by inertia, so
  rotation_acceleration means rad/s^2 and all three axes match. Yaw is
  unchanged.
- pitch_down pitched the nose UP: get_axis's arguments were reversed, so
  the I/K keys and the stick each did the opposite of their label.

Menus were unusable on a pad for a separate reason: Godot 4.7 gives
ui_up/down/left/right joypad events by default but leaves ui_accept and
ui_cancel with none (verified against a pristine project), so a controller
could move the highlight and never press anything. A confirms and B goes
back. Gameplay exits on a new leave_gameplay action (Escape / Start) rather
than ui_cancel, so carrying B for menus cannot abandon a live match.

Bindings for both devices are rebindable in Settings -> Controls, persisted
to user://input.cfg — a separate file from settings.cfg because
VideoSettings.save() rewrites that file wholesale and would drop any
section it does not know about. project.godot stays the source of truth for
defaults; overrides are only ever a delta on top of a boot-time snapshot.

Verified: 268 unit tests, the ENet integration gate, and a 16-sample
before/after comparison of networked prediction residuals showing the
physics change does not regress them (median 0.083m -> 0.065m).

Note for follow-up: every policy in Game/bots/ was trained against the old
sluggish, world-axis rotation and will over-rotate until retrained.

Game/scripts/settings_menu.gd

@@ -1,6 +1,10 @@
 extends Control
 
-# Settings screen: player-facing video knobs on top of VideoSettings (the
+# Settings screen root, owning the Video tab and the shared Back button. The
+# Controls tab has its own script (controls_settings.gd) so this file stays
+# video-only; both tabs' state is committed in _on_back_pressed below.
+#
+# Video tab: player-facing video knobs on top of VideoSettings (the
 # autoload holding + persisting them). Preset/AA/vsync/fps-cap/resolution
 # scale apply immediately since they're Viewport- or DisplayServer-wide;
 # glow/brightness/shadow/SDFGI/SSIL/SSAO apply the next time an arena loads
@@ -205,6 +209,10 @@ func _mark_custom_if_user_driven() -> void:
 
 func _on_back_pressed() -> void:
 	VideoSettings.save()
+	# Bindings are applied live as the player rebinds them (InputSettings.apply
+	# runs on every change) but are only committed to disk here, matching how
+	# the video knobs behave.
+	InputSettings.save()
 	get_tree().change_scene_to_file(ScenePaths.MAIN_MENU)