fix(notifications): guard UN calls when running unbundled (fixes tauri dev crash)

[AzimovS]

Summary

pnpm run tauri dev / ./clean_run.sh crashes at startup on macOS with:

*** Terminating app due to uncaught exception 'NSInternalInconsistencyException',
reason: 'bundleProxyForCurrentProcess is nil:
mainBundle.bundleURL file:///.../target/debug/'

Commits #32 / #33 migrated macOS notifications from tauri-plugin-notification (legacy NSUserNotification, which delivers on unbundled binaries but no longer fires banners on modern macOS) to UNUserNotificationCenter. The modern UN API dereferences NSBundle.mainBundle and throws when the executable was launched directly rather than from a .app bundle. tauri dev runs target/debug/meetily (not the bundled .app), so UN crashes the app before the window even opens.

Fix

Add an is_running_in_app_bundle() guard in frontend/src-tauri/src/notifications/macos_un.rs that checks whether current_exe() has a *.app ancestor, and early-return from the two UN entry points when unbundled.

Two subtleties worth calling out:

1. request_authorization returns Err, not Ok(false). manager.rs:60-62 persists the result via set_system_permission(granted). Dev runs and the bundled .app share the same config directory (~/Library/Application Support/com.meetily.ai/notification_settings.json), so returning Ok(false) would write system_permission_granted = false to disk and silently suppress every real notification in the shipped app until the user manually re-granted consent. Returning Err hits the existing Err arm at manager.rs:69-72 which logs and continues without persisting — no cross-build poisoning.
2. show() returns Ok(()). Callers propagate the Result upward but do not store state on success, so a silent no-op is safe in dev.

Bundled .app behavior is unchanged — the guard only fires when the ancestor walk finds no .app.

Test plan

• cargo check clean
• ./clean_run.sh (= pnpm run tauri dev) on macOS: app starts; logs show UN authorization skipped: not running inside a .app bundle (likely \tauri dev`)followed byNotification system initialized successfully`. No crash.
• Build the .app (pnpm run tauri:build or ./clean_build.sh) and launch it directly → first-run macOS permission prompt appears; test notifications fire as banners.
• Verify system_permission_granted in ~/Library/Application Support/com.meetily.ai/notification_settings.json is not overwritten by a tauri dev run.

Known follow-ups (intentionally out of scope)

• Lifting the capability check into system.rs so macos_un.rs stays a pure UN transport.
• A dev fallback to tauri-plugin-notification so devs get some banner delivery during tauri dev (at the cost of keeping the legacy dep on macOS).
• Replacing path-sniffing with NSBundle.mainBundle.bundleIdentifier().is_some() for a more authoritative signal.