refactor(spotlight): registry-driven CMDK preferences

[ajnart]

Summary

Stacked on #4915 (feat/rework-perferences).

Replaces the per-preference CMDK children files with a unified, data-driven preference system:

• Enriched preference definitions — each definition now carries a mutationGroup field linking it to the correct tRPC mutation, enabling data-driven dispatch
• Unified preference registry — preference-registry.tsx auto-generates CMDK children via createStaticChildren and createAsyncSelectableChildren factory functions, replacing 5 separate files
• Rewritten hook — useUserPreferences reduced from ~347 to ~160 lines by deriving mutation dispatch, pending state, and optimistic values from definitions
• Simplified consumers — settings-children.tsx and groups.tsx now iterate over visiblePreferenceDefinitions instead of maintaining manual per-key mappings

Adding a new preference now only requires:

1. Add entry to definitions.ts with mutationGroup
2. Add icon + children factory to preference-registry.tsx
3. Add translations

Net reduction: ~261 lines across 9 files, with 5 files deleted.

Test plan

• Open CMDK → verify all preferences appear and filter correctly
• Toggle boolean preferences (openSearchInNewTab, ddgBangs, pingIcons) → verify optimistic UI and persistence
• Change select preferences (colorScheme, locale, firstDayOfWeek) → verify children drill-down and value update
• Change board-based preferences (homeBoardId, mobileHomeBoardId) → verify async loading and selection
• Change search engine → verify async loading and selection
• "Full preferences page" link → navigates to manage page
• Test as guest → only colorScheme and locale visible
• Verify manage page preferences still work independently