Fix macOS notification activation

[Marc-André Moreau (mamoreau-devolutions)]

• I have read the contributing guidelines, and I agree with the Code of Conduct.
• Have you checked that there aren't other open pull requests for the same changes?
• Have you tested that the committed code can be executed without errors?
• Have you confirmed that this issue is caused by UniGetUI itself, and not by the package manager or the package involved?
  If the same issue can be reproduced outside UniGetUI with the relevant package manager or with the package itself, please report it there first. UniGetUI should only be used to track issues that are specific to UniGetUI's behavior or integration.

---

Problem and symptoms

On macOS, clicking UniGetUI's new-version notification opens Script Editor instead of foregrounding UniGetUI. The same incorrect association affects package-update and operation notifications because all use the same delivery bridge.

The bridge spawned /usr/bin/osascript and used AppleScript's display notification. macOS attributes those notifications to the AppleScript host, whose default click behavior activates Script Editor; AppleScript notifications cannot provide an application click handler.

Fix

Replace osascript delivery with a bundled UNUserNotificationCenter Objective-C bridge. The bridge reports the default notification response to NativeAOT-safe C# interop, which posts MainWindow.ShowFromTray() to Avalonia's UI thread. Debug and release macOS builds compile an architecture-matched dylib beside the executable, where the existing packaging/signing step includes it.

---

N/A