Fire buttons on press where the browser never delivers a release

Every button in the web build was dead - reported as "Play does nothing".

Diagnosed on the deployed build with a temporary on-screen input probe,
because none of it reproduces here: the suite passes, and pressing Play under
the real gl_compatibility renderer (the same path WebGL2 takes) reaches
Main.tscn fine. The probe reported, from a phone browser:

    #6 touch down @ 362,781
    play rect 296,725 128x128
    hit=YES

Three taps, six events, every one a DOWN and not a single UP - and the button
left drawn in its bright held state, pressed_down stuck true because nothing
ever came to clear it. So touches arrive, their coordinates are correct, and
they land inside the button; the browser simply never delivers the release,
in _gui_input or in raw _input.

IconButton emits `pressed` only on release, deliberately, so that dragging
off a button cancels it. With no release that means it never emits at all -
on every button in the game, not just Play. Which also explains why the
earlier suspects went nowhere: the scene change was never reached, so it was
never the scene change, and hit=YES ruled out coordinate mapping.

fire_on_press defaults to OS.has_feature("web"). There, a press completes the
tap itself and does NOT latch, since nothing is coming to unlatch it. Every
other platform is untouched and keeps drag-off-to-cancel.

The cost, stated plainly: a web tap can no longer be cancelled by sliding off
before lifting, and that applies to destructive buttons too. The alternative -
keeping release-firing and treating a new press as completing the previous
one - preserves cancellation but leaves the very first tap dead, which is
worse.

tests/test_icon_button_press_fires.gd drives the flag directly, since a
headless Linux run cannot BE a web build: one tap emits exactly once, a late
release does not emit again, the button does not latch, and with the flag off
the release still drives the press and dragging off still cancels.

MainMenu keeps the load/start bisection introduced while chasing this - a
failed change_scene_to_packed otherwise leaves the menu up, which looks
exactly like an unpressed button.

Full suite green at 100/100.

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

IconButton.gd

@@ -110,6 +110,24 @@ func _blocked_by_modal() -> bool:
 	return false
 
 
+# Fire on the PRESS instead of the release.
+#
+# A browser on a phone delivers the touch down and then never delivers the
+# release. Measured directly on the deployed build: presses arrive with
+# correct coordinates, land inside the button, and the button visibly latches
+# into its held state - and no release ever follows, in _gui_input or in raw
+# _input. A button that only emits on release therefore never emits at all,
+# which is exactly the "Play does nothing" report.
+#
+# The cost is the drag-off-to-cancel affordance below, which is worth much
+# less than the button working. Everywhere else keeps it, because everywhere
+# else delivers releases.
+#
+# Settable rather than a constant so a test can exercise both paths without
+# needing to be a web build.
+@export var fire_on_press: bool = OS.has_feature("web")
+
+
 func _gui_input(event: InputEvent) -> void:
 	if _blocked_by_modal():
 		return
@@ -125,6 +143,12 @@ func _handle_press(is_pressed: bool, at_position: Vector2) -> void:
 	if is_pressed:
 		pressed_down = true
 		queue_redraw()
+		if fire_on_press:
+			# Nothing is coming to complete this press, so complete it here.
+			# Not latched: with no release to clear it, the button would
+			# otherwise stay drawn in its held state forever.
+			pressed_down = false
+			pressed.emit()
 	elif pressed_down:
 		pressed_down = false
 		queue_redraw()