[Arkex-ai]

Summary

With the default menu shortcut, Esc releases the mouse. Opening and closing the menu with F1 later could grab it again. F1 now restores capture only if the mouse was captured when F1 opened the menu. The opt-in Esc shortcut still restores the capture it released.

Closes #2031.

Technical changes

• Send the opening shortcut with the existing menu-state message. Windows and SDL use it to decide whether to restore capture released by Esc.
• Keep the opening reason and requested menu state in the same SDL atomic. Discard the remembered Escape capture on focus loss.

Validation

• At 1519603d on d47206ed, the pointer fixture passed on Windows LLVM and Ubuntu Clang 18. It checks default Esc then F1, opt-in Esc, and F1 while captured on both host paths.

• The Windows shortcut suite and all 18 window-procedure cases in the screensaver fixture passed. The first hosted Windows run found a stale two-argument test stub for the updated menu handler. The stub now matches the handler.

• On the first revision, two negative controls independently reproduced stale recapture in the Windows and SDL host paths. In a Windows Kokiri smoke test at 600960cd, the default Esc-then-F1 sequence, direct F1, and opt-in Esc opening returned to gameplay. The run exited normally and preserved the original checkpoint hashes. Cursor confinement was asserted in the fixtures; the native run verified the menu transitions.

• Both hosted Windows source shards pass at this head. Main includes the startup fixture fix from test(display): the startup fixture stubs driver_cache_room (main is red since #2033) #2051.

Current-head check	Result
Linux AppImage	Passed
Windows build	Passed
Source suite	Passed