Let Windows users turn on notifications after a false denial

[BradGroux]

Addresses #2445.

What Windows users saw

Buzz could report desktop notification permission as denied before Windows
had registered the app as a notification sender. The settings toggle then
treated that value as final, so users could not turn notifications on even
though requesting permission would repair the state.

Why it happened

The settings flow only called requestDesktopNotificationAccess() when the
reported permission was default.

On the affected Windows path, Tauri's injected notification shim can initialize
Notification.permission as denied. Calling
Notification.requestPermission() repairs the state and returns granted, but
Buzz never made that request after the false denial.

What changed

• Add explicit Windows platform detection.
• Add ensureDesktopNotificationPermission() to keep the transition policy
  small and testable:
  • default requests access on every platform, preserving existing behavior;
  • denied retries once on Windows;
  • denied remains terminal on macOS, Linux, and the web.
• Use the helper in the real notification settings toggle.
• Extend the Playwright notification bridge to model a false denied state,
  the later granted result, and the exact request count.
• Add unit and settings-flow regressions.

There is no retry loop, Tauri plugin fork, new dependency, or change to
notification delivery itself.

Regression coverage

• Windows denied → one request → granted
• non-Windows denied → no request
• default → request on Windows and non-Windows
• Win32 platform detection without the former Darwin false-positive risk
• the real settings path: blocked permission → toggle on → one request →
  granted → toggle enabled

Verification

Verified at commit 500753b900a4a52275b8870fb91e04f731d96c23.

• just ci
  • all Rust unit and conformance groups passed
  • Desktop: 3,405 passed
  • Desktop native: 1,560 passed, 13 ignored
  • Mobile: 529 passed, 1 skipped
  • Desktop, native, web, and mobile static/build gates passed
• installed-Chrome Playwright regression
  Windows retries a false denied notification permission from settings —
  1 passed
• independent specification and standards reviews — no findings

One unrelated native process-group harness test returned a transient macOS PGID
of -1 during an intermediate full run. It passed immediately in isolation and
again in the subsequent full just ci runs, including the final commit above.

What still needs a real Windows test

The automated regression uses a Windows platform identity and exercises the
real Buzz settings hook against the notification shim. It does not run inside
Windows WebView2 or Tauri.

Keep #2445 open until an affected Windows 11 installation passes this smoke
test:

1. Start from the false denied state described in the issue.
2. Enable desktop notifications in Buzz settings.
3. Confirm the permission request returns granted and the setting changes to
   On.
4. Confirm Buzz appears under Windows System > Notifications.
5. Trigger a real Buzz notification and confirm the toast arrives.

That final check is required before claiming the Windows shell integration is
fixed.