fix(D196): re-hide the OS cursor after the F10 options overlay closes

inputSuspendForOverlay() forces the OS cursor visible while the overlay is
open; on close nothing re-hid it unless reconcileGrab() happened to re-grab
(only true if the user had already clicked-to-lock in a stage). Opening the
overlay from a menu, or from a stage not yet click-locked, left the cursor
stuck visible over the game's own crosshair.

Fix: re-assert applyCursorVisibility() once per controller-0 poll, right
after reconcileGrab(). Unreachable while the overlay is open (early return
above), so it only fires once the overlay has closed and self-heals every
poll thereafter. Port-only, no render change; verify.sh bunker1 PASS.

Owed: 5-second visual check - open F10 from a menu, close it, cursor gone.

port/src/input.c

@@ -520,6 +520,13 @@ unsigned inputComputePad(int idx, signed char *stick_x, signed char *stick_y)
                         current_menu != GE_MENU_INVALID);
 
         reconcileGrab(menuMode);
+        /* D196: the F10 options overlay forces the OS cursor visible via
+         * inputSuspendForOverlay() but nothing re-hides it on close unless
+         * reconcileGrab() happens to re-grab (only true if you had already
+         * clicked-to-lock in a stage). Re-assert the correct visibility
+         * every poll here -- this line is unreachable while the overlay is
+         * open (early return above), so it only fires once it has closed. */
+        applyCursorVisibility();
 
         /* Click-to-lock, in a stage, cursor free: the mouse buttons must not
          * reach the game (no phantom fire) -- the first click only re-locks