Windows: Desktop alerts cannot be enabled — "Desktop notifications are blocked for Buzz", and the setting is force-disabled on every launch

### Summary

On Windows, enabling **Settings → Notifications → Desktop alerts** fails with the red notice
"Desktop notifications are blocked for Buzz" and the switch reverts. Nothing on the machine is blocking
notifications. This is an upstream `tauri-plugin-notification` bug that makes `Notification.permission` report
`"denied"` on Windows regardless of the real state — but Buzz amplifies it by re-deriving `desktopEnabled` from that
value on every launch, so there is no way for a user to work around it.

Upstream issue: https://github.com/tauri-apps/plugins-workspace/issues/3557

### Environment

- Buzz 0.5.20, unsigned installer, per-user install at `%LOCALAPPDATA%\Buzz`
- Windows 11 Pro 10.0.22631
- WebView2 Runtime 151.0.4129.107 (Evergreen, system-wide)
- `tauri-plugin-notification` 2.3.3, `wry` 0.55.1, `webview2-com` 0.38.2

### What is NOT the cause (all verified)

- **Start Menu shortcut has a correct AppUserModelID.** `Buzz.lnk` property store holds FMTID
`{9F4C2855-9F79-4B39-A8D0-E1D42DE1D5F3}` PID `5` = `xyz.block.buzz.app`.
- **WebView2 profile has no stored denial.**
`%LOCALAPPDATA%\xyz.block.buzz.app\EBWebView\Default\Preferences` →
`content_settings.exceptions.notifications` is `{}`, and there is no non-default
`default_content_setting_values`.
- **No blocking registry values**, and no Edge/WebView2 notification policies under
`HKCU`/`HKLM\SOFTWARE\Policies`.
- **Windows global toast switch is on.**
- **The native toast path works end to end** — a test notification was delivered and Buzz was registered under
`HKCU\...\Notifications\Settings\xyz.block.buzz.app` with `PeriodicNotificationCount: 1`.

### Actual behaviour

`tauri-plugin-notification`'s init script sets `window.Notification.permission = "denied"` at startup on Windows
without querying the backend, while the backend returns `granted`. Verified in a live Buzz webview:

```
Notification.permission => "denied"
raw backend: is_permission_granted => true
raw backend: request_permission => "granted"
await Notification.requestPermission() => "granted"
Notification.permission => "granted"
```

With permission corrected to `"granted"`, the Desktop alerts toggle turns on normally and the setting is written to
`localStorage`:

```
key: buzz-notification-settings.v2:
value: {"desktopEnabled":true,"homeBadgeEnabled":true,"notifyWhileViewing":true,...}
```

**But the setting does not survive a restart.** On the next cold start, with no workaround applied:

```
Notification.permission (fresh boot) => "denied"
desktopEnabled => false
full setting object => {"desktopEnabled":false,"homeBadgeEnabled":true,"notifyWhileViewing":true}
```

Note that `homeBadgeEnabled` and `notifyWhileViewing` both survive — only `desktopEnabled` is reset. So this is not a
general settings reset; `desktopEnabled` is specifically re-derived from `Notification.permission` during boot and
forced off.

Because Buzz's own code runs *after* the plugin's init script, a user cannot correct this from devtools either: by
the time `requestPermission()` can be called, `desktopEnabled` has already been overwritten. The result is that
desktop notifications are permanently unreachable on Windows for this version.

### Suggested change

Two things, either of which unblocks users:

1. **Don't force `desktopEnabled` off from a cached permission value.** Treat an explicit user opt-in as
authoritative and let the send path fail loudly if it ever actually fails. At minimum, don't silently rewrite a
persisted user setting during boot.
2. **Call `await Notification.requestPermission()` before reading `Notification.permission`** on Windows. This
round-trips to the Tauri backend and returns the true value (`"granted"`), sidestepping the upstream bug until
the fixed plugin version ships.

### Impact

Desktop toast notifications are unusable on Windows in 0.5.20. In-app indicators still work — `homeBadgeEnabled`
is unaffected because it does not go through the Notification API.