feat(desktop): self-update from GitHub Releases (signed + notarized)

[hay-kot]

Purpose

Let the installed Hive desktop app update itself from GitHub Releases: an auto-update toggle in System settings, a title-bar "update available" chip that downloads + relaunches into the new version, and a hardened macOS release pipeline (Developer ID signing + notarization) so the swapped .app passes Gatekeeper.

Implements epic hc-hs74vlj4.

Proposed Changes

• Custom updater provider (desktop/updater_provider.go) scoped to the desktop-v* tag namespace — the stock GitHub provider can't see desktop releases as newer because they share the repo with CLI v* tags. Lists releases, filters by prefix, compares semver, picks the single .zip, and attaches the SHA256 digest from SHA256SUMS; delegates Download to the stock provider.
• UpdaterService (desktop/updaterservice.go) with a self-managed poll ticker (the framework's CheckInterval has no runtime setter), Status/SetEnabled/CheckNow/InstallUpdate, and a release-build gate (dev builds skip Init).
• Settings (internal/desktop/settings.go): AutoUpdate *bool (unset ⇒ default on) + load-modify-save fix so fields no longer clobber each other.
• Frontend: auto-update toggle + "Check for updates" in System settings; title-bar update chip wired to InstallUpdate; regenerated Wails bindings.
• Release workflow: Developer ID codesign (hardened runtime + entitlements), notarize + staple, publish SHA256SUMS sidecar.

Digest-only verification for now; Ed25519 signature verification is a follow-up. Windows/Linux are out of scope (macOS-only workflow today) but the provider/service are OS-agnostic.

Required repository secrets (one-time setup)

The release workflow needs six secrets from your Apple Developer account. Add each under Settings → Secrets and variables → Actions → New repository secret.

Signing certificate → MACOS_CERTIFICATE, MACOS_CERTIFICATE_PWD, MACOS_SIGN_IDENTITY

You need a Developer ID Application certificate (the cert type for distribution outside the Mac App Store).

1. Create it — Xcode → Settings → Accounts → your team → Manage Certificates → + → Developer ID Application. (Or on the web: Certificates, IDs & Profiles → Certificates → + → Developer ID Application.)
2. Export as .p12 — In Keychain Access, find Developer ID Application: <Name> (TEAMID), expand it so the private key is included, right-click → Export → .p12, and set a password.
   • That password → MACOS_CERTIFICATE_PWD
3. Base64-encode the .p12:

   base64 -i Certificates.p12 | pbcopy

   • The blob → MACOS_CERTIFICATE
4. Get the identity string after importing the .p12 into a keychain:

   security find-identity -v -p codesigning

   • Use it verbatim, e.g. Developer ID Application: Jane Doe (AB12CD34EF) → MACOS_SIGN_IDENTITY

Notarization API key → AC_API_KEY_ID, AC_API_ISSUER_ID, AC_API_KEY

App Store Connect → Users and Access → Integrations tab → App Store Connect API → Team Keys → +. Give it the Developer access role.

• On generation you get a Key ID → AC_API_KEY_ID
• The Issuer ID at the top of that page → AC_API_ISSUER_ID
• Download the .p8 key (⚠️ downloadable once only), then base64-encode it:

  base64 -i AuthKey_XXXXXXXX.p8 | pbcopy

  • The blob → AC_API_KEY

Gotchas

• Requires the paid Apple Developer Program — a free Apple ID can't create a Developer ID Application cert.
• TEAMID is your 10-char Apple Team ID (App Store Connect → Membership).
• The .p8 API key is used (instead of Apple-ID + app-specific password) to avoid 2FA prompts in CI.
• Until these secrets exist, the desktop-publish workflow will fail at the signing step. The self-update runtime code works regardless; only the signed/notarized release build needs them.

Checklist

• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)