Panic shortcut: free a trapped cursor from the keyboard

[mgth]

Closes #526.

A cursor stuck on a screen it cannot leave puts every recovery LBM offers — Undo, Stop, the tray menu — behind a click that cannot be made. The eleven closed "cursor gets stuck" issues were all geometry bugs and were fixed as such; none of them left the user a way out while it was happening. Live update (#525) sharpens it, since an untested geometry now goes under the mouse deliberately, but the need stands on its own.

Hold Ctrl+Alt+Shift+M for about a second. Configurable under Options → Mouse.

Who decides what

The daemon does one thing and always the same thing: release the clip, say so, take the hook down. It knows nothing about why, and that is the point — it has to work with no UI reachable behind the very cursor it is freeing, or with no UI running at all.

What the rescue should mean belongs to the UI, which is where the knowledge is:

• previewing a layout → there is an experiment to throw away: drop live update, reload the saved layout, start the engine again on it;
• not previewing → what trapped the user is what they committed to, and leaving the engine down is the answer.

So the ordinary case is over in one press. Nothing counts presses and there is no escalation window; the escalation falls out of the state.

Rescued is broadcast before the unhook is requested. The other order puts the resulting Stopped first, the UI drops live preview on that, and the Rescued behind it finds nothing left to act on — the reload never happens.

Three deliberate choices in the listener

• RegisterHotKey, not WH_KEYBOARD_LL. The daemon already hooks the mouse globally; a keyboard hook would mean seeing every keystroke on the desktop — a keylogging surface that antivirus and anti-cheat notice, and that a mouse utility has no business needing. This sees one combination, and Windows arbitrates collisions instead of leaving them silent. Verified from another process: the combination answers ERROR_HOTKEY_ALREADY_REGISTERED.
• Its own thread, with its own message loop. WM_HOTKEY goes to the queue of the thread that registered; registering on the hook pump would make the rescue depend on the pump it is rescuing you from.
• Held, not tapped, with the auto-repeat backlog drained afterwards so letting go cannot fire a second time.

Recording it

Pressed, not typed: the daemon can only register what Windows understands, so a name typed in and unmappable there would be accepted here and fail silently, far from its cause.

Sent the moment it is recorded, through a new Shortcut command, rather than riding to the daemon inside the next Apply. That was the first thing to get wrong — recording one and waiting for an Apply meant nothing was attempted, so nothing succeeded and nothing failed, and there was no way to tell "it works" from "something else owns it". It still travels inside the layout as well, which is what gets one to a standalone daemon replaying its startup file.

When RegisterHotKey refuses, the daemon says so and the options row says the combination is taken and the rescue is NOT active. A rescue that silently does not exist is worse than none, because the user only finds out at the moment they need it.

The key table covers letters, digits, function and navigation keys, punctuation and the numeric keypad. Without the last two, Ctrl+² could not be recorded at all — on a French keyboard that is most of the interesting keys. OEM keys are named by position rather than by what they print: Oem3 is ` on QWERTY and ² on AZERTY, and the position is what gets registered, so a shortcut means the same physical key whatever the layout says it prints. The button therefore reads Ctrl+Oem7, which is honest but not pretty — prettifying it needs a MapVirtualKey round-trip and can come later.

That grammar is a contract between two languages and two processes with no compiler behind it. ShortcutBoxTests and shortcut.rs's tests are the compiler: every name locked on both sides, along with the refusals — a bare key (registering one globally would take it from every application on the desktop) and keys with no virtual-key code.

Also fixed, because adding an event made it blocking

Both daemon event handlers ended in default: throw new ArgumentOutOfRangeException, and Suspended, Resumed and Probed have a case in neither — every sleep, resume and probe was faulting them from inside a Dispatcher.Post. An event stream you do not control is ignored, not refused; a daemon newer than its UI is a normal state of affairs.

Not possible, and worth writing down

Two modifiers alone — both Shift keys together, say. RegisterHotKey takes modifiers plus a key, and there is no key in that. The only way round is a keyboard hook, which is the surface this design exists to avoid.

Linux gets nothing yet: no global shortcut without a portal, and reading one from evdev means opening the keyboard devices.

Tests

105 + 60 + 113 + 5 managed, 56 Rust, clippy clean.