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

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: tauri-apps/plugins-workspace#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:<account-key>
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.