fix(desktop): enable native Windows toast notifications

[fatima-n09]

Description:

  Fixes #6377

Problem
  Desktop notifications are impossible to enable on Windows. The app
  shows "Desktop notifications are blocked. Enable them in your system
  settings." even when notifications are enabled in Windows Settings.
  The Buzz app doesn't appear in Settings > System > Notifications,
  so users can't control per-app notification preferences.

Root cause

  show_native_notification only handled Linux and macOS — on Windows
  it returned an error. The frontend fell through to window.Notification
  (WebKit/WebView2 API), but WebView2's Notification.permission reports
  "denied" even when the WinRT toast API is available. The app never
  registered itself with the Windows notification system.

Fix

  - Add tauri-winrt-notification as a Windows-specific dependency
  - Add a windows module in notifications.rs that posts WinRT toast
    notifications using the app's Tauri identifier as AppUserModelID
    (this registers the app with Windows Settings > Notifications)
  - Handle click actions through WinRT Activated handler, forwarding
    to the same native-notification-activated event that Linux uses
  - Add isWindowsPlatform() helper to platform.ts
  - Skip WebView2 Notification.permission check on Windows in
    getDesktopNotificationPermissionState() — use the Tauri plugin's
    isPermissionGranted() which queries native WinRT status
  - Route Windows through the native show_native_notification path
    in sendDesktopNotification()
  - Skip the Tauri plugin's onAction listener on Windows (click
    actions come through the native WinRT event instead)

Files:

  1. desktop/src-tauri/Cargo.toml          — +tauri-winrt-notification dep
  2. desktop/src-tauri/src/commands/notifications.rs — +Windows toast module
  3. desktop/src/features/notifications/lib/desktop.ts — permission + routing
  4. desktop/src/shared/lib/platform.ts     — +isWindowsPlatform()
  5. desktop/src/shared/lib/platform.test.mjs — 10 tests, all passing ✔

Tests added:

  - isWindowsPlatform: Win32, Win64, macOS, Linux, undefined navigator
  - isMacPlatform: MacIntel, Win32
  - isLinuxPlatform: Linux, Android, Win32

[Chessing234]

this overlaps #6678 — both add a windows toast path (winrt vs the tauri plugin). please pick one; if this is the native path, drop the plugin send on windows so we don't double-fire.

[fatima-n09]

@Chessing234 Thanks for the review! You're right about the overlap with #6678.

My PR uses the native WinRT path (tauri-winrt-notification) which:
1. Registers the app with Windows Settings > System > Notifications
   (AppUserModelID)  the Tauri plugin doesn't do this
2. Handles click actions through WinRT's on_activated handler

The Tauri plugin's sendNotification() is never called on Windows
in this PR. sendDesktopNotification() routes Windows through
invoke("show_native_notification") and returns immediately  the
plugin path is unreachable. listenForDesktopNotificationActions()
also skips the plugin's onAction listener on Windows since clicks
come through the native WinRT event instead.

So there's no double-firing risk even if both PRs merge. That said,
if #6678 merges first, its sendNotification() block for Windows
would be dead code. Happy to coordinate with @Cynthia427 on merge
order.