Improve Ableton Live shortcut support

[shibco]

This change improves keyboard and mouse shortcuts in Ableton Live when Live
runs through this project's Wine build.

It includes:

• Live Alt shortcuts, such as Alt+4, no longer leave the menu bar selected.
• Alt with a mouse action no longer leaves the menu bar selected.
• Alt by itself and menu shortcuts, such as Alt+F, continue to work.
• ABLETON_SHORTCUTS=take ableton-live can temporarily turn off the exact
  GNOME Ctrl+Alt+Up and Ctrl+Alt+Down entries. For Live 11, it also turns off
  the exact Ctrl+Alt+Delete entry.
• The launcher restores the saved GNOME entries after all Live sessions exit.
  It also recovers after a stopped process and keeps shortcut changes that the
  user makes while Live runs.
• The default launcher mode does not change desktop shortcuts.

The automatic desktop change supports GNOME only. It does not change KDE or
another desktop. This change also does not alter AltGr behavior.

The saved tests check exact GNOME entry matching, recovery, handled Alt keys,
Alt with a mouse action, Alt+F, and Alt by itself. The Wine test returns an
error when a required result fails.

The short guide is in notes/ABLETON-WINE-SHORTCUT-PARITY.md. The detailed
research and open checks are kept in notes/ABLETON-WINE-SHORTCUT-AUDIT.md.

[ClickSentinel]

Reviewed at 150e642. Read 0070 against base-5c23dd1c; ran patch-check, a full build with build-audit, test-shortcut-hold.sh, and A/B probes on a scratch Xvfb display against the installed 0001-0065 runtime. Live was not in the loop, and this box is COSMIC, so the GNOME hold was exercised through the library's own functions and real gsettings get values.

Verified. patch-check clean (67 entries, series applies to pristine base). Build clean, build-audit 4/4, series 0001..0070. Merge against main: already up to date. 37/37 shortcut-hold checks. altnum-menu-repro before/after: swallow prohibited=9 exit 1 -> prohibited=0 exit 0, pass identical in both, alt_f={1,1,1} and bare_alt={1,1} green in all four runs. 0069 is the only other delta in that A/B and touches window.c alone, so the difference is 0070's. The Alt+click exposure the audit lists as unobserved is now observed: unpatched, the swallowed click arms the bar and the follow-up F opens File.

Blocking

• Hold does not survive losing XDG_RUNTIME_DIR. The snapshot lives only at $XDG_RUNTIME_DIR/ableton-wine-shortcuts/hold-v2 (shortcut-hold.sh:97-112). That path is tmpfs and goes with the session; dconf does not. A reboot or logout with Live running destroys the snapshot while the stripped bindings persist, and no later launch can recover them - Ctrl+Alt+Up/Down are gone permanently, silently. Measured with the shipped test's own gsettings stub: hold -> wipe the runtime dir -> relaunch leaves up=['<Super>Up'] down=[]. Both docs promise the opposite ("restore them after a crash", "the next launch finds the saved values"). Fix: snapshot under ${XDG_STATE_HOME:-$HOME/.local/state}/ableton-wine/, leave locks and lease.* in the runtime dir. The existing no-Live-no-lease rule then heals across reboots unchanged.

Should fix

• f10_key behaviour is not unchanged for pass-through apps, and nothing tests it. The patch message claims it is; altnum-menu-repro.c has no F10 stage. Measured on a pass-through window: F10 down/up arms in both runtimes, F10 down, A down, A up, F10 up arms in neither, F10 down, A down, F10 up, A up arms before and not after. Base only breaks the arm on the intervening keyup (defwnd.c:2789), so this ordering genuinely changes - plausibly toward Windows per the patch's own QF_FMENUSTATUSBREAK premise, which I could not verify independently. Fix: narrow the claim to the Alt path, and add that third case to the repro.
• 0070 has no off switch. It rewrites the input retrieval path for every process under the runtime - plugin GUIs, Max, the installer - and swapping whole runtimes was the only way to A/B it. Precedent is mixed (0055/0062/0065/0069 have one, 0049-0054 do not), but this one sits on the hot path for every message. Fix: gate both cancel_menu_key_state() calls on a WINE_WIN32_MENU_KEY_BREAK=off read once.

Comment only

• Audit note's line anchors do not resolve against base-5c23dd1c as it states - button-down clear is base defwnd.c:2749 cited 2758, arm 2760 cited 2768, keyup SC_KEYMENU 2786 cited 2795; message.c is mixed. Mechanism verified correct, anchors only. Fix: re-cite, or say which tree they are from.
• ABLETON_SHORTCUTS treats anything not exactly take as preserve with no message, where ABLETON_TOPBAR_MODE warns (ableton-live:760). =Take or =on would look like it worked. Fix: one warn line.
• SERIES_GAPS[0057] is stale - 0057 ships and fingerprints, but is still listed as reserved. The numbering loop only consults the table for genuinely missing numbers, so it passes silently. Pre-existing. Fix: drop the entry.
• altnum-menu-repro.exe takes the foreground and issues SendInput key and button events; BUILDING.md says only that it needs a working Wine display. Fix: one sentence pointing at xvfb-run.

Held

menu_sys_key is armed only from DefWindowProc (defwnd.c:2760) and fires at keyup (:2786), so a consumed chord key reaches neither - the mechanism is as described. Both insertion points are right: the keyboard cancel lands after VK_LMENU/VK_RMENU fold to VK_MENU and before dispatch, so bare Alt and F10 still arm; the mouse cancel lands while msg->message is still the untranslated button-down (reassigned only at message.c:2809), so it covers non-client and double-click cases. WM_SYSCHAR never reads the flag, only clears it (:2793), which is why mnemonics survive. No other patch in the series touches either static. The strip parser is correct against this box's real values, including keeping '<Super><Alt>Left' while removing '<Control><Alt>Left' from the same array.