release

# Cutting a cctop Release Releases are triggered by pushing a `v*` tag. `.github/workflows/release.yml` then runs: build (arm64 + x86_64, zip + DMG each) -> sign and notarize -> create GitHub Release -> update Sparkle appcast on master -> update Homebrew cask. ## Authorization and checks - Treat an explicit request to **release**, **cut**, or **ship** a version as authorization for the complete release: assess scope, run proportionate checks, bump and land the version, push the tag, supervise publication, and verify downstream metadata. Do not insert another routine approval gate when all expected checks pass. - A request to **prepare**, **assess**, or **check whether ready** is not publication authorization. Stop before the tag and ask for the final go. - Before proposing or adding any release check, state its reason in plain language: name the concrete failure or release risk it covers and why the shipped changes make that risk relevant. Do not propose a check merely because an older or larger release used it. - Scale checks to the release. Previously approved PR tests are feature evidence; release checks should cover integration, versioning, packaging, and risks introduced by the exact release range. Patch releases should not inherit major-release manual tests without a specific reason. - Once an authorized release's checks pass, continue automatically. Stop only when a check fails unexpectedly, the release range/version is ambiguous, unrelated changes appear, publicati...