fix: improve quarantine handling for applications outside standard folders

[duongductrong]

Overview

This pull request resolves an issue where Snapzy incorrectly flags itself as quarantined and blocks permissions after being upgraded via Homebrew Cask (brew upgrade).

Problem

Homebrew Cask upgrades perform file operations (like moving or copying) using command-line tools that preserve the com.apple.quarantine extended attribute on the application bundle. Even though Snapzy is Apple Notarized and macOS Gatekeeper handles the quarantine clearance automatically upon first launch, Snapzy's AppIdentityManager detects the quarantine flag and treats it as a hard block. This results in a false positive that prevents the app from working, forcing users to completely uninstall and reinstall the app to clear the permissions lock after every upgrade (see #337).

Solution

Modified the quarantine check logic in AppIdentityManager.swift:

• We now check if the application is running from standard Applications paths:
  • /Applications/ (System-wide applications)
  • ~/Applications/ (User-specific applications)
• If the application is located in one of these directories, we skip flagging it as quarantined. Gatekeeper handles the quarantine-to-clearance flow for notarized apps, and checking it here within standard directories is unnecessary and prone to Cask-upgrade false positives.
• If the app is run from outside these directories (e.g. ~/Downloads), the quarantine check remains active and behaves as expected.

Key Changes

• Modified evaluate() in AppIdentityManager.swift:
  • Added a path prefix check using NSHomeDirectory() to resolve standard system/user application directories.
  • Restricted the .outsideApplications and .quarantined warnings to only fire if quarantined is true AND the app is outside standard applications directories.

Closes

• Fixes [Bug]: 真的太烦了，每一次更新都会丢失权限！！！都需要完全卸载再重新安装。 #337