fix(desktop): deliver Windows notifications and clear false "blocked" banner

[Cynthia427]

Problem

On Windows, the desktop app's Settings → Notifications pane shows two red banners at once — "Desktop notifications are blocked. Enable them in your system settings." and "Desktop notifications are blocked for Buzz…" — the enable toggle bounces straight back to off, and no notification sound ever plays. None of this is caused by the user's Windows settings, and no Windows setting can clear it.

Root cause

The app runs in WebView2 on Windows, whose DOM Notification.permission reports "denied" by default even though native toasts are actually delivered by the Tauri notification plugin (notification:default capability, already wired up).

1. getDesktopNotificationPermissionState() trusted that DOM value before ever consulting the plugin, so it returned "denied" on Windows → the "blocked" banner shows and the enable toggle is refused.
2. Because the toggle can't turn on and sendDesktopNotification() bails out early on a non-granted state, didSend is false, so playNotificationSound() (an in-app <audio> element, independent of the OS toast) never fires — hence no sound.
3. Separately, sendDesktopNotification() posted only via the DOM Notification API on Windows, which WebView2 does not surface as an OS toast.

macOS (WKWebView, native UN delegate) and Linux (WebKitGTK, D-Bus backend) don't hit this because their permission and delivery paths differ.

Fix

• Permission detection: on Windows under Tauri, read the notification plugin (isPermissionGranted()) as the source of truth instead of the misleading WebView2 DOM value. Clears both banners, unblocks the toggle, and lets the in-app sound play.
• Delivery: route Windows sends through the plugin's sendNotification() (native Windows toast). Click-through arrives via the existing onAction listener (already registered for non-Linux/non-macOS), which reads the target from extra; silent: true avoids doubling the app's own notification sound.
• Adds an isWindowsPlatform() helper. macOS and Linux paths are unchanged.

Test plan

• tsc --noEmit — clean
• Biome — clean
• Desktop unit tests — full suite green (5397 passing) via pre-push hooks; notification suite green locally
• Needs a Windows box (can't be verified from macOS): with a packaged build, confirm the banners are gone, the toggle turns on, a mention/DM while backgrounded plays the sound and shows a native Windows toast, and clicking the toast opens the right conversation. Note: Windows only surfaces toasts for an installed app, so verify on a packaged build, not a raw tauri dev run.

[Chessing234]

sendNotification isn't awaited, so the try/catch never sees a plugin failure and you return true before the toast exists. also this overlaps #6689 which takes the native winrt path — please pick one.