feat(updater): add Sparkle Stage 1 - minimal UpdateService, menu, and guards (opt-in)

[3manu31]

feat(updater): add Sparkle Stage 1 - minimal UpdateService (opt-in)

What does this PR do?

• Adds a minimal, opt-in in-app updater integration using Sparkle via SPM.
• Wires an UpdateService that initializes Sparkle's updater controller (without starting it automatically) and exposes checkForUpdates().
• Adds a Check for Updates command in the app menu to trigger the updater.
• Keeps a safe fallback: when no SUFeedURL is present the button opens the GitHub Releases page.

This is a conservative Stage 1 change intended only to add the UI hook and updater wiring so maintainers can review without needing CI secrets, appcast signing, or release-process changes.

Type of change

• Bug fix
• New feature (opt-in, non-invasive)
• Performance improvement
• UI/UX enhancement
• Documentation
• Other (describe)

Files changed

• project.yml — add Sparkle SPM package and target product dependency
• PureMac/Services/UpdateService.swift — new minimal updater service
• PureMac/PureMacApp.swift — add Updates command menu and Check for Updates button
• PureMac/ViewModels/AppState.swift — small concurrency fix (MainActor wrap for Logger call)
• PureMac.xcodeproj/project.pbxproj — Xcode project updated to include Sparkle/package entries

Why this change

• Stage 1: Introduce a safe, reviewable integration that does not require signing keys or CI changes.
• Keeps the codebase ready for a separate Stage 2 PR that would add appcast generation and signed updates.

Related issues

• Related: [Feature] Auto Updates #94

Testing done

• Built locally: xcodegen generate → open PureMac.xcodeproj → Build succeeded.
• Runtime: Tested on macOS Tahoe (26). Check for Updates opens Releases when SUFeedURL is not set; when SUFeedURL is present Sparkle's updater is started and checks for updates.

How to test locally

1. Ensure xcodegen is installed: brew install xcodegen
2. Generate project: xcodegen generate
3. Open in Xcode: open PureMac.xcodeproj
4. Build & run. From the app menu: Updates → Check for Updates.
   • With no SUFeedURL in the app's Info.plist the app opens the GitHub Releases page (safe fallback).
   • When maintainers add a feed URL + signed appcast, Sparkle will handle update checks.

Notes for reviewers

• This PR is intentionally minimal and conservative. It adds no CI changes, no signing keys, and no production appcast generation.
• If maintainers want Stage 2 (signed appcast, CI workflow updates), I can prepare a separate PR describing the required secrets and workflow changes.

AI-assistance disclosure

Drafted using Claude Code. Built the project locally to confirm my version compiles. I understand what the code does.

[momenbasel]

Thanks for the Stage 1 design — the opt-in shape (no automatic checking, GitHub Releases fallback when SUFeedURL is unset) is exactly the right way to land Sparkle without committing to an appcast yet. Two things before this can merge:

1. Rebase against current main. #103 just landed and rewrites the trashDirectly callback signature in AppState.swift, so this PR conflicts. While you're rebasing, please drop the AppState.swift change entirely — wrapping Logger.shared.log in Task { @MainActor in ... } was a workaround for a concurrency warning that #103 fixed by a different route (the whole closure is now hopped onto MainActor via Task { @MainActor in } from the outside). The Sparkle PR shouldn't need to touch AppState at all.

2. Stage 2 follow-up. Please open a tracking issue for Stage 2 covering: appcast generation in the release workflow, EdDSA signing key management (where the private key lives, how releases sign the appcast), Info.plist additions (SUFeedURL, SUPublicEDKey), and any helper-bundle code-sign/notarize implications for Sparkle's Autoupdate.app and Updater.app. I'm happy to land Stage 1 as-is once the conflict is resolved, but I don't want the Sparkle dep sitting in main without a plan for the signed-update path.

Tag #94 so it tracks back to the feature request. Thanks again.