Sign and notarize the macOS application

## Problem

An unsigned macOS bundle does not provide the trusted installation experience expected from a downloadable desktop application.

## Distribution and signing decision

- Distribute Draftgoblin outside the Mac App Store as a DMG published through GitHub Releases.
- Use the existing paid Apple Developer Program membership to sign with a Developer ID Application identity and submit releases to Apple's notarization service.
- Do not introduce a Mac App Store listing, App Review, Store sandboxing, or Store-specific packaging.

## Findings

- Developer ID is Apple's signing path for applications distributed outside the Mac App Store. The existing paid Apple Developer Program membership covers Developer ID certificates and notarization without an additional Apple fee.
- The existing iOS/App Store distribution certificate is not suitable. The Apple Developer team's Account Holder must create a Developer ID Application certificate and export its certificate and private key as a password-protected `.p12` for CI.
- A Developer ID Installer certificate is only required for a signed `.pkg`; it is not needed for a drag-to-Applications DMG.
- Notarization is an automated malware and code-signing check, not App Review. It does not create an App Store listing.
- Prefer an App Store Connect Team API key with the Developer role for `notarytool` authentication. Individual API keys do not work with `notarytool`; Apple ID and an app-specific password remain an alternative.
- Notarization requires a valid Developer ID signature, Hardened Runtime, secure timestamps, correctly signed nested code, and no enabled `com.apple.security.get-task-allow` entitlement.
- Draftgoblin does not need App Sandbox for direct distribution. Start with no permissive hardened-runtime entitlements and add only an entitlement demonstrated to be necessary by the packaged application.
- The current PySide/Nuitka deployment can use Nuitka's `--macos-sign-identity` and `--macos-sign-notarization` support. Bundled executables, Qt frameworks, dynamic libraries, plugins, and helpers must be signed deterministically before the outer application bundle; do not use `codesign --deep` as a signing shortcut.
- The release sequence is: build the application, sign nested code and the application, verify it, create and sign the DMG, submit the DMG with `notarytool`, wait for acceptance, staple and validate the ticket, test the mounted artifact, and publish that exact DMG.
- GitHub Actions can perform the complete build, signing, notarization, stapling, and automated installation smoke test on a hosted macOS runner. Apple credentials should be available only to intentional tag releases through a protected GitHub environment.
- CI can verify signatures, Gatekeeper assessment, notarization, mounting, installation, launch, and the representative Arena-log workflow. A final download from GitHub Releases on a clean supported Mac is still required to exercise browser-applied quarantine and the real first-launch Gatekeeper path.
- Signing does not determine CPU compatibility. The supported macOS architectures must be selected explicitly, and CI must verify the final executable rather than implicitly inheriting an undocumented runner architecture.

## CI credentials

Store the following in a protected macOS release environment:

- Secret: base64-encoded Developer ID Application `.p12`.
- Secret: `.p12` export password.
- Secret: App Store Connect Team API `.p8` private key.
- Variable or secret: App Store Connect API key ID.
- Variable or secret: App Store Connect API issuer ID.
- Variable or secret: Apple Developer Team ID.

Create the signing keychain and its password ephemerally during the job, then remove the keychain and decoded credential files even when the job fails. Pull requests and ordinary development builds remain unsigned and receive no Apple credentials.

References:

- [Apple: Developer ID](https://developer.apple.com/developer-id/)
- [Apple: Create Developer ID certificates](https://developer.apple.com/help/account/certificates/create-developer-id-certificates/)
- [Apple: Notarizing macOS software before distribution](https://developer.apple.com/documentation/security/notarizing-macos-software-before-distribution)
- [Apple: Customizing the notarization workflow](https://developer.apple.com/documentation/security/customizing-the-notarization-workflow)
- [Nuitka: macOS signing options](https://nuitka.net/user-documentation/user-manual.html)

## Proposed change

Create a signed, notarized, and stapled macOS application distributed as a drag-to-Applications DMG through GitHub Releases. Keep unsigned development bundles separate from the protected tag-release signing path.

## Acceptance Criteria

- [ ] A Developer ID Application certificate and App Store Connect Team API key are created and stored through a protected GitHub release environment.
- [ ] The application and every bundled executable, framework, dynamic library, plugin, and helper are signed with the correct Developer ID Application identity before the outer bundle is signed.
- [ ] Hardened Runtime and secure timestamps are enabled, and only runtime-proven minimal entitlements are applied and documented.
- [ ] CI verifies the application with strict `codesign` validation and Gatekeeper assessment before packaging.
- [ ] The signed application is packaged in a signed drag-to-Applications DMG.
- [ ] The DMG passes Apple notarization through `notarytool`, and the returned ticket is stapled and validated before publication.
- [ ] Both the arm64 and x86_64 bundles from #347 are signed, notarized, and verified against their final executables in CI.
- [ ] CI mounts the final DMG, installs and launches the application, discovers the seeded Arena log, completes the representative workflow, removes the application, and unmounts the DMG.
- [ ] A clean supported Mac downloads the published DMG from GitHub Releases and verifies the real first-launch Gatekeeper experience.
- [ ] The exact signed, notarized, stapled, and tested DMG is published through GitHub Releases; Mac App Store publication remains outside scope.
- [ ] Signing, installation, release, credential rotation, notarization failure, Gatekeeper troubleshooting, and uninstallation instructions are documented.