fix(shortcuts): make the global show/hide window shortcut opt-in and configurable

[Th-Underscore]

Closes #1971.

Description

Sable currently registers Ctrl+Shift+S as a system-wide show/hide hotkey on startup, unconditionally and non-configurably - hijacking the key from every other application (it collides with "Save As" in most of them). This makes the shortcut:

• Opt-in: nothing is registered until the user assigns a binding. Absent/null/empty settings all mean "unregistered", and Sable no longer claims any global key on its own.
• Configurable: a new Show/Hide Sable entry in Settings -> Keyboard Shortcuts. Assigning a binding registers it with the OS first - a binding the OS rejects is never persisted - and clearing it (Backspace/Delete) unregisters immediately. Changes apply live; startup re-registers whatever was saved.
• Plumbing: a new set_global_window_shortcut Tauri command persists to the desktop settings store and re-registers, menu.rs reads the binding from the store on boot, and a toTauriAccelerator converter maps captured web bindings to Tauri accelerator strings.

Tested on the desktop app, Ubuntu 24.04, as well as Windows 11 when I first built this a couple weeks ago.

One thought that's deliberately out of scope for this PR: since the shortcut is now off by default, new users have no natural way to discover it. It may be worth a one-time notification or a hint somewhere pointing at Settings -> Keyboard Shortcuts, so the feature doesn't become invisible to everyone who'd actually want it.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation - .changeset
• My changes generate no new warnings

AI disclosure

• Partially AI assisted
• Fully AI generated (explain what all the generated code does in moderate detail)

I hit this bug myself and tested the builds; the code was AI-generated. The Rust side stores the binding under the existing desktop-settings store (globalWindowShortcut key), register_global_shortcuts treats missing/null/empty as unregistered, and the command unregisters-all then re-registers the new binding. The frontend adds the shortcut definition with a null default, the capture flow routes through the command before persisting, and an effect keeps the OS registration in sync with the persisted value.