fix: robust global hotkey registration with informative conflict errors

[4Roman]

Problem

When a global hotkey fails to register, the current behaviour has a few rough edges:

• In the bulk registration pass, the ? operator bailed on the first error, so a single conflicting/invalid binding silently disabled all the remaining hotkeys.
• After an unclean shutdown, a restart, or a previously failed attempt, a shortcut could stay tracked internally as "already registered" for the lifetime of the process, so re-registering it (even pressing OK again in settings) kept failing.
• The error shown to the user ("failed to register hotkey") gives no hint about why.

Changes

• Independent registration: register each hotkey separately in the "all" pass and collect failures, so one conflict no longer disables the others.
• Clear stale state: call unregister_all() before bulk (re)registration, plus force-unregister + a short retry per shortcut, fixing the "already registered" desync left by unclean shutdowns / restarts / failed attempts.
• Informative errors (Windows): add a small conflict probe (hotkey_owner.rs) that classifies the failure (free / held by another app / OS error) and names the owner for well-known system shortcuts; the user-facing error and the startup notification now state exactly which hotkey failed and why.
• OK always re-grabs: removed the isRegistered pre-check in the Hotkey settings so pressing OK reliably re-claims the shortcut for pot.

Honest limitation

Windows exposes no public API to map a global hotkey back to its owning process, so for arbitrary third-party apps the message can only say "held by another application — pick a different combination". Only well-known OS shortcuts are named.