Windows: desktop notifications never register; UI reports a system-settings block that doesn't exist

**Describe the bug**
The "Desktop alerts" toggle in Settings → Notifications is permanently disabled on Windows. Clicking it shows "Desktop notifications are blocked for Buzz. Enable them in system settings to turn alerts on." Only "Home badge" can be changed.

The message is misleading: nothing is blocked at the OS level. Buzz has never registered with Windows notifications at all — there is no grant *and* no denial recorded anywhere, so the permission request appears never to reach the OS.

**Steps to reproduce**
1. Install Buzz on Windows 11 and sign in
2. Go to Settings → Notifications
3. Click the "Desktop alerts" toggle
4. Toggle does not engage; red banners appear: "Desktop notifications are blocked. Enable them in your system settings." and "Desktop notifications are blocked for Buzz. Enable them in system settings to turn alerts on."
5. Open Windows Settings → System → Notifications — Buzz is not listed, so there is nothing to enable

**Expected behavior**
Clicking "Desktop alerts" should trigger the notification permission request, register Buzz with Windows (making it appear under Windows Settings → System → Notifications), and enable desktop alerts. If permission is genuinely unavailable, the error should say why rather than pointing at a system setting that doesn't exist yet.

**Version and platform**
- Buzz version: 0.5.17
- OS: Windows 11 Pro 25H2, build 26200.9168 (WebView2 151.0.4129.93)

**Logs / additional context**
Verified the entire OS-side path is configured and permissive:

- `HKCU\...\CurrentVersion\PushNotifications\ToastEnabled` = `1` (enabled)
- Do Not Disturb / Quiet Hours: not configured
- Start Menu shortcut present with a correct AUMID:
`Buzz.lnk` → AUMID `xyz.block.buzz.app`, target `E:\Buzz\buzz-desktop.exe`
- 58 other applications are registered under `HKCU\...\CurrentVersion\Notifications\Settings`
- **Buzz has no key there at all** — neither enabled nor disabled
- WebView2 profile `EBWebView\Default\Preferences`:
- `profile.content_settings.exceptions.notifications` = `{}`
- `profile.default_content_setting_values` = `{}`

No grant and no denial in either location means the request never reached Windows.

Analysis: the WebView runs at `http://tauri.localhost` (Tauri + WebView2). WebView2 returns `denied` for the Web Notification API unless the host application handles `NotificationReceived`. The UI appears to treat any non-`granted` state as a system-level block, so a permission that was never actually requested surfaces as "blocked in system settings."

Since the AUMID is already registered correctly by the installer, routing notifications through Tauri's native notification plugin should work without additional host setup.

Happy to test a fix — this machine has a provably clean OS-side configuration.