fix(settings): clear orphaned per-prompt shortcuts on legacy retirement

[shivanshsen7]

Description

Retiring the legacy secondary-prompt-mode hotkey (retireLegacySecondaryPromptShortcutIfNeeded()) clears PromptModeHotkeyShortcut / PromptModeSelectedPromptID, but never touches DictationPromptConfigurations — a separate, still-active data store used by the current "Custom shortcut per AI Prompt profile" feature.

dictationPromptShortcutAssignments() turns every stored .shortcut in DictationPromptConfigurations into a live global hotkey unconditionally, with no dependency on PromptModeShortcutEnabled or either retirement flag. Any residual .shortcut left over from before the legacy hotkey was retired — most commonly a bare Command keypress under the __default__ entry — keeps firing forever, even though nothing in Settings shows or lets you clear it.

This matches the two independent reports on #675: both show the exact same orphaned keyCode: 55 (Command) under __default__, despite having different Primary Dictation shortcuts configured (Right Option / Right Control). That consistency across unrelated users is why I'm confident this is leftover legacy state rather than an intentional per-profile shortcut.

This PR clears any stale .shortcut bindings once, at the same retirement boundary that already governs PromptModeHotkeyShortcut, while preserving any real providerID/modelName overrides a user may have set on a prompt configuration.

Type of Change

• 🐞 Bug fix
• ✨ New feature
• 💥 Breaking change
• 🧹 Chore
• 📝 Documentation update

Related Issue or Discussion

Fixes #675

Testing

• Tested on Intel Mac
• Tested on Apple Silicon Mac
• Tested on macOS version: 26.5.2
• Ran linter locally: swiftlint --strict --config .swiftlint.yml Sources (SourceKit crashes on this machine — only Command Line Tools installed, no full Xcode; see note below)
• Ran formatter locally: swiftformat --config .swiftformat Sources — diffed --lint output against unmodified main for both touched files; this change introduces zero new formatting findings (45 pre-existing findings unrelated to this change, unchanged before/after)
• Ran tests locally (blocked — see note below)

Note on local verification: this machine only has Command Line Tools, not full Xcode, so xcodebuild test isn't available and swiftlint crashes on a missing sourcekitdInProc framework. I verified both changed files parse cleanly with xcrun swiftc -parse, and confirmed with swiftformat --lint that this diff adds no new style issues. I also manually reproduced the exact preference-file shape from #675 on my own affected install (DictationPromptConfigurations.__default__.shortcut = {keyCode: 55, modifierKeyCodes: [55]}, PromptModeShortcutEnabled = false) and applied the equivalent of this fix via defaults delete as a live workaround, which stopped Command from triggering dictation without disturbing the configured Primary Dictation shortcut. The new regression test reproduces that same data shape and asserts dictationPromptShortcutAssignments() — the source GlobalHotkeyManager reads for these hotkeys — ends up empty after cleanup. CI (build.yml, macos-latest with full Xcode) should be able to run the full suite including this test.

Screenshots / Video

• No UI/visual changes; screenshots/video are not applicable.

Notes

clearOrphanedDictationPromptShortcuts() clears .shortcut on every entry in DictationPromptConfigurations, not just __default__, since the legacy single-shortcut system could plausibly have left residue under __privateAI__ or a profile:* key too. The tradeoff: if anyone genuinely used the current "Custom shortcut" editor (Advanced AI Settings → prompt editor → "Custom shortcut") to bind a shortcut before updating past this migration, that binding would also be cleared. Given both #675 reports show the identical keyCode: 55 artifact regardless of their actual configured Primary Dictation shortcut, I believe this is safe, but happy to narrow the scope (e.g. only __default__, or only shortcuts matching the known legacy default) if you'd prefer — you have visibility I don't into how many users use per-profile custom shortcuts today.