fix(notifications): restore macOS banners + Debug dropdown to verify

[AzimovS]

Summary

Two changes that are best shipped together because the first proves the second is real:

• feat: Debug Notifications dropdown in About (ae62910). A per-type "fire this notification now" dropdown next to "Debug Updater". Uses the real production code path so consent toggles are exercised, not bypassed. Single repro surface for every NotificationType.
• fix: macOS banners via UNUserNotificationCenter (584dc5b). The fix the dropdown immediately uncovered: notifications reported success and landed in Notification Center, but banners never appeared on macOS 26.

The macOS bug

tauri-plugin-notification → notify-rust → mac-notification-sys uses [NSUserNotificationCenter deliverNotification:]. NSUserNotification was deprecated in macOS 10.14 (2018) and its banner path has been broken on modern macOS for years. On macOS 26, every API contract returns success but no banner ever fires. Upstream fix is stalled: mac-notification-sys PR #51 (draft since Nov 2025), tauri plugins-workspace RFC #2134 (no PR).

What changed

• On macOS, SystemNotificationHandler::show_notification dispatches to a new macos_un module that uses UNUserNotificationCenter directly via objc2-user-notifications. A UNUserNotificationCenterDelegate whose willPresent returns .banner|.list|.sound is installed once (retained in OnceCell) so foreground-app notifications produce banners — the real fix.
• On Windows and Linux, tauri-plugin-notification is unchanged.
• Authorization flows through the real requestAuthorizationWithOptions — which means first launch of this build re-prompts for notification permission. NS and UN grants live in separate slots.
• NotificationPriority::Critical maps to UNNotificationInterruptionLevel::TimeSensitive, not Critical. Real Critical requires Apple's Critical Alerts entitlement we don't have.

Deps added (macOS-only): objc2, objc2-foundation, objc2-user-notifications, block2.

Testing

Manually verified on macOS 26.4.1 from an ad-hoc-signed debug bundle. All 8 DebugNotificationKind variants produce visible top-right banners within ~1s, each with the Meetily icon and an entry in Notification Center.

• Recording started → banner
• Recording stopped → banner
• Recording paused → banner
• Recording resumed → banner
• Transcription complete → banner
• Meeting reminder → banner
• System error → banner
• Generic test → banner
• Logs: Installed UNUserNotificationCenterDelegate (willPresent → Banner|List|Sound) once, UN present: id=... title=... level=... per send
• cargo check clean (same preexisting warnings, no new ones)
• Windows build (cfg-gated, paths untouched, smoke-test in CI if configured)
• Linux build (same)

Docs updated

• docs/solutions/build-errors/macos-dev-build-notifications-and-signing.md: new Phase 2: NS → UN migration section covering root cause, solution, re-prompt behavior, and gotchas specific to the new path (cb753b9)
• frontend/src-tauri/NOTIFICATION_TESTING.md: reworked troubleshooting around UN authorization state, Alert Style, Focus / Scheduled Summary / Deliver Quietly, and the killall usernoted kick (cb753b9)

Caveats for reviewers

1. First-launch re-prompt. Existing users will see a fresh "Would meetily like to send notifications?" prompt on the first run of this build because the NS-era grant does not transfer. Document in the release notes.
2. tauri dev still can't deliver banners — UNUserNotificationCenter requires a valid CFBundleIdentifier, which tauri dev doesn't provide. Test from a built bundle (see solution doc).
3. No fallback to the plugin on UN errors. If addNotificationRequest fails, we surface the error to the caller (same contract as before) rather than silently trying the broken NS path. Logs include the underlying NSError localized description.

Post-Deploy Monitoring & Validation

This is a local desktop app with no production backend — no dashboards, no log queries. Validation is user-driven.

• Healthy signal (user-reported). Banner fires from About → Debug Notifications within ~1s on macOS 13+.
• Failure signal (user-reported). "I clicked Debug Notifications and nothing appears." First triage step: await window.__TAURI_INTERNALS__.invoke('get_notification_stats') in DevTools — system_permission_granted must be true. If not, follow the re-prompt procedure in NOTIFICATION_TESTING.md.
• Rollback trigger. If multiple macOS users report zero banners after a fresh install and they've clicked Allow on the prompt. Rollback is a one-commit revert of 584dc5b — the non-macOS path is unchanged and isolated by cfg.
• Validation window. Watch the first week of releases; Sherkhan as owner.
• Cross-platform. Windows/Linux users: no behavior change expected. A regression there means a cfg-gate mistake — inspect frontend/src-tauri/src/notifications/system.rs.

🤖 Generated with Claude Code