Fix release notarization and stamp Sparkle version at release time

[austin-smith]

What Changed

Notarization fix (v0.8.3 release failure):

• Added an Export Developer ID app step (xcodebuild -exportArchive, method developer-id) between archive and DMG creation. Sparkle's nested helpers (Autoupdate, Updater.app, both XPC services) ship ad-hoc signed; export re-signs all nested code with the Developer ID identity and secure timestamps. Copying the app straight out of the xcarchive left the ad-hoc signatures in place, and Apple's notary service rejected the submission (status: Invalid).
• The DMG and verification steps now use the exported app. Verification additionally asserts Sparkle's Autoupdate is no longer ad-hoc signed and that the app's CFBundleVersion matches the release tag.
• The notarize step now checks the verdict explicitly — notarytool submit --wait can exit 0 on an Invalid verdict, which previously surfaced as a confusing stapler error. Any non-Accepted status dumps Apple's per-file notarytool log into the job output and fails immediately.

Versioning:

• The project keeps ordinary version fields: one MARKETING_VERSION (0.8.3) and one plain CURRENT_PROJECT_VERSION (1, reset per version bump), shared by every target. No derived settings in the project file; Xcode's Version/Build panes look and behave as standard.
• The Sparkle feed compares CFBundleVersion, so the release workflow stamps the marketing version into it at archive time via a CURRENT_PROJECT_VERSION="${TAG#v}" build-setting override — released DMGs carry CFBundleVersion == marketing version, and every Sparkle release bumps the marketing version. The workflow's verify step fails the release if the stamp is missing.
• New ProjectVersionConsistencyTests: fails the suite (and therefore PR CI) if MARKETING_VERSION or CURRENT_PROJECT_VERSION values diverge anywhere in project.pbxproj — Xcode's per-target Version/Build panes can silently fork the values apart when edited by hand.

Why

The v0.8.3 release failed notarization (first release with an embedded framework). Separately, version numbers needed to be maintainable in one place: with two app targets, Xcode's General pane edits can fork MARKETING_VERSION per target and drift out of sync unnoticed.

Validation

• Release build with the CI override stamps CFBundleVersion 0.8.3 / marketing 0.8.3; a plain local build stamps 1 / 0.8.3; Xcode shows single unsplit Version/Build fields.
• Consistency tests verified in both directions: they failed against a deliberately forked project file (0.8.3 vs 6.6.6) with both values named in the message, and pass on the clean file.
• Reproduced the notarization failure locally: archives built per the old pipeline leave Sparkle's nested binaries ad-hoc signed (codesign -dvv shows Signature=adhoc), which Apple rejects.
• Verified the notary verdict parsing against the actual output of the failed run; ExportOptions.plist lints clean; workflow YAML and shell syntax validated.

After merge: delete and re-push the v0.8.3 tag (nothing was published under it — the release job died before creating the GitHub release, and no appcast was deployed).

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.

[austin-smith]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Nice work!

Reviewed commit: 16112821e7

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".