fix(hotkeys): name the combo another app already owns

Two gaps when Windows refuses a RegisterHotKey:
- the toast said "one or both hotkeys" — wrong since there are three autofill
  combos, and it never said which one lost.
- Quick search and New entry failures were only written to the debug panel,
  which is off in production: the hotkey silently did nothing with no clue why.

Delphi now exposes the per-slot registration outcome and the host accumulates
the failed combo names across all five hotkeys, emitting one notification for
the batch. A combo the user deliberately cleared (vk=0) is never listed.
JS names them: "Already used by another app: 2FA code — pick another combo in
Settings".

Registration stays best-effort per slot: one clash doesn't disarm the others.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

delphi-backend/Source/PM.Bridge.pas

@@ -202,6 +202,12 @@ type
     property SecureClipboard: TSecureClipboard read FSecureClipboard;
     property TrayAdded: Boolean read FTrayAdded;
     property AutofillRegistered: Boolean read FAutofillRegistered;
+    // Per-slot outcome of the last SetAutofillHotkeys — lets the host name
+    // exactly which combo lost the race with another app's global hotkey
+    // instead of a vague "one of them failed".
+    property AutofillFullActive: Boolean read FAutofillFullActive;
+    property AutofillPwdActive:  Boolean read FAutofillPwdActive;
+    property AutofillTotpActive: Boolean read FAutofillTotpActive;
     // Fired on main thread when Windows locks the session (WTS_SESSION_LOCK).
     property OnSystemLock: TProc read FOnSystemLock write FOnSystemLock;
     // True once WM_QUERYENDSESSION (or WM_ENDSESSION) has been received.