feat(ci): sign and notarize the macOS binary, verify it on macOS

[tenequm]

Why

The darwin binary is cross-compiled from Linux (cargo zigbuild) and was ad-hoc signed. It is never built or run on macOS before shipping, so two things could reach users unnoticed:

• A binary that cannot launch. That is the class of bug ops/scripts/patch-macos-sdk.py exists for, and it does not degrade gracefully: the Homebrew formula calls generate_completions_from_executable at install time, so a dead binary breaks brew install itself.
• No publisher identity. Ad-hoc carries no team, no chain to Apple. Blocks MDM-managed Macs and rules out ever shipping a cask, .app, or .pkg.

What

release-prep -> dist-build (pond-ci)      build + Developer ID sign
             -> macos-verify (macos-15)   launch -> signature -> notarize
             -> publish-release (pond-ci) crates.io, release, tap, flake

publish-release is split so the macOS checks gate the publish without re-running the four-target build; needs: does all the sequencing and publish rehydrates dist/ from an artifact.

Signing and notarization ship together deliberately. Gatekeeper has an explicit [Unnotarized Developer ID] P0 deny execute rule, so a Developer ID signature without notarization is strictly worse than ad-hoc.

Notes on two non-obvious choices

spctl is not used to verify. It rejects every bare CLI binary regardless of notarization — verified against a known-good notarized binary:

$ spctl --assess --type exec -vv /usr/local/bin/docker
/usr/local/bin/docker: rejected (the code is valid but does not seem to be an app)

So macos-verify asserts the two properties notarization actually requires (Developer ID authority, hardened runtime flag) instead.

The notarization gate is the JSON status, not the exit code. notarytool submit --wait exits 0 even when the notary returns Invalid.

Credentials

A CI-dedicated Developer ID Application certificate, separate from the interactive one, so it is independently revocable. Its private key is not in any local keychain. Notarization uses an App Store Connect API key (notarytool supports no other auth that can be exported).

Verified before this branch existed

The full chain was run locally against Apple with these exact commands and credentials:

step	result
rcodesign sign via the moon.yml code path	Developer ID + hardened runtime + secure timestamp
codesign assertions	pass on signed, fail on ad-hoc
notarytool submit --wait	{"status":"Accepted"}

Before merging

.github/workflows/dry-run-apple-signing.yml is temporary and must be deleted. It mirrors dist-build + macos-verify on pull_request (the production jobs only fire on a release push), giving this PR a real signed and notarized rehearsal.

It does not exercise publish-release, whose changes are mechanical: artifact download instead of in-job build, V from a job output.