fix: route native notification clicks back to the page

[yhcharles]

Problem

Pake replaces window.Notification with a bridge to tauri-plugin-notification, but that plugin is fire-and-forget on desktop: show() hands the notification to notify_rust and drops the handle, so nothing ever reports which notification the user clicked. The page's own click routing therefore never runs, and a packaged Slack/Discord/etc. never jumps to the conversation a notification came from — arguably one of the most common reasons someone would package a chat site with Pake in the first place.

Fix

macOS now delivers notifications itself through NSUserNotificationCenter with a delegate, tagging each one with <window label>|<id>. A click reveals the originating window through the same unminimize + show + reapply_window_icon + focus sequence as every other hidden-to-visible path (#1323), then hands the exact id back to that webview. Availability is probed once on the main thread during setup, so a process without a bundle identifier (e.g. pnpm run dev) or a future macOS without the deprecated API falls back to the plugin path instead of dereferencing nil. Other platforms keep the existing plugin path unchanged — this PR is macOS-first, since that's where the native click-report API is available today.

The page-side notification is now a real EventTarget rather than a bare object with an onclick slot, so addEventListener("click", ...) works and event.target is the notification itself — matching the standard Notification API pages actually code against. It also carries the standard tag/data/icon fields, lets a same-tag notification replace its predecessor, and caps how many stay click-addressable.

The focus heuristic Pake used before (treat regaining focus shortly after a notification as a click) is now a fallback only where the platform reports nothing: it fires once, requires the notification to have been raised while the window was unfocused, expires after 60s, and is cancelled by any in-page interaction. Rust reports nativeClick so macOS disables the heuristic entirely and an ordinary app switch cannot fire a phantom click.

Notification ids are minted by the packaged (untrusted) page and echoed into a native identifier and a webview eval, so they're validated against a strict charset and length on the Rust side before use.

Why NSUserNotification and not UserNotifications.framework

The whole NSUserNotification family is deprecated in favor of UserNotifications.framework, but that framework needs a provisioned bundle and a permission prompt that a webpage wrapper can't meaningfully ask for. It's also the API tauri-plugin-notification already reaches through notify-rust, so this isn't a new deprecated surface for the project — and the code probes for the class at startup, so a macOS version that finally drops it falls back to the plugin path rather than crashing.

Verification

• cargo test --lib — 50 passed, including new coverage in src-tauri/src/app/notification.rs
• npx vitest run — 510 passed, including tests/unit/notification-bridge.test.js (new)
• cargo clippy --all-targets — no new warnings
• cargo fmt --check, prettier --check — clean
• Not yet verified: a real click-through on a packaged chat site on macOS. Happy to record that before merge if useful.

[tw93]

@yhcharles Thanks for the contribution. This is merged and shipped in pake-cli 3.17.3: on macOS a notification click now reopens and focuses the window that raised it, and Windows and Linux keep the focus-based fallback. Your follow-up in #1408 landed in the same release.

Run npm install -g pake-cli@3.17.3 and rebuild an app to get it.