Implement a public auto-updating Nightly channel

[xcv58]

Goal

Implement one Nightly deliverable: a public, clearly warned, Developer ID-signed and notarized MacTools Nightly release that users install once and subsequently update through the app's existing Sparkle UI.

There is no second Nightly artifact or channel in this proposal. The existing manually generated MacTools-Debug Actions artifact remains an ordinary CI debugging tool outside this scope; it is not scheduled, published, or promoted as Nightly.

Draft PR #245 currently documents the target and handoff. The public Nightly implementation is not complete.

Target user experience

1. A user opens GitHub Releases and selects a public prerelease titled MacTools Nightly — Unstable.
2. The release begins with a clear warning that Nightly may contain unfinished features, regressions, or data-format changes.
3. The user downloads a Developer ID-signed and notarized MacTools Nightly installer once.
4. Nightly installs beside stable MacTools with separate app/extension identities, URL scheme, preferences, Application Support directory, and plugins.
5. The app's existing Check for Updates flow discovers, verifies, installs, and relaunches newer Nightly builds from a dedicated Sparkle feed.
6. The matching same-commit plugin set is synchronized automatically before plugins load.
7. Stable MacTools, its data, update feed, plugin catalogs, Homebrew metadata, and GitHub Latest remain untouched.

Nightly is public. No account, invitation, access control, private download service, or separate marketing website is required.

Contributor implementation before draft PR #245 is ready

These items can be implemented and reviewed without upstream release credentials:

• Nightly isolation: add a dedicated build configuration for the app and Finder extension with separate product names, bundle IDs, URL scheme, defaults scope, Application Support/plugin paths, and visible Nightly channel metadata.
• Update configuration: make the Sparkle feed/public key and plugin source/public key build-configurable; assign every successful Nightly a monotonically increasing numeric build version.
• Publication workflow: add a dedicated workflow gated by ENABLE_NIGHTLY_RELEASES that references maintainer Secrets, runs tests, builds with Release settings, signs/notarizes, creates an immutable public GitHub prerelease, puts the instability warning first, and advances the dedicated appcast only after every app/plugin asset is available.
• Atomic plugins: build the app and plugins from the same commit and PluginKit version, then synchronize the matching Nightly plugin set before plugin loading even when production plugin versions did not change.
• Stable protection: keep publication fail-closed and prove that stable storage, docs/appcast.xml, docs/app-release.json, Homebrew, GitHub Latest, and production plugin catalogs cannot be modified by the Nightly path.
• Tests and documentation: cover configuration isolation, build numbering/appcast generation, package/catalog integrity, plugin synchronization, publication ordering, and stable-channel protection; finish the public warning, retention, rollback, troubleshooting, and changelog documentation.

A new Xcode target is not required if a dedicated Nightly configuration provides complete isolation. A separate Nightly Sparkle key is recommended but may reuse the stable key if the maintainer explicitly accepts that tradeoff. A remote Nightly plugin catalog is optional if the app ships and synchronizes a complete matching plugin baseline.

Maintainer activation after merge

Scheduled publication must remain disabled until a maintainer completes the credential-backed acceptance that cannot run in a contributor fork:

• Confirm the Developer ID, notarization, bundle-prefix, Sparkle-key, and any plugin-catalog-key configuration.
• Manually publish Nightly N and N+1.
• Install N and use Check for Updates to install N+1; verify signatures, notarization, relaunch, warning copy, matching plugins, and stable-app isolation.
• Confirm retention and rollback by publishing known-good source as a new higher build rather than replacing immutable signed bytes.
• Set ENABLE_NIGHTLY_RELEASES=true, verify the next scheduled prerelease/feed update, and confirm the pause/resume and troubleshooting instructions.

Deleting or changing ENABLE_NIGHTLY_RELEASES pauses scheduled Nightly publication. Manual validation remains available while paused.

Acceptance criteria

• GitHub publicly lists a clearly warned MacTools Nightly — Unstable prerelease with a signed/notarized installer.
• A user installs Nightly once and later updates normally through the in-app Sparkle flow.
• Nightly and stable MacTools coexist without sharing app identity, data, plugins, or update settings.
• Nightly uses a dedicated appcast with monotonic builds and never changes stable release metadata.
• App and plugin packages come from the same commit and compatible PluginKit version; matching plugins synchronize automatically.
• Scheduled publication is opt-in, pausable, resumable, manually testable, and fail-closed.
• Contributor-testable behavior is covered in CI, and a maintainer completes the credential-backed N-to-N+1 flow before enabling the schedule.

Non-goals

• A second Debug or contributor Nightly channel.
• Access control, accounts, invite codes, or private downloads.
• Homebrew Nightly distribution.
• Marking Nightly as GitHub Latest.
• Reusing the stable appcast or production plugin catalog.
• A separate marketing website.
• Silent background installation; normal Sparkle prompts and Check for Updates are sufficient.