ci: release-binaries clobbers locally-notarized assets; Apple signing secrets unset so CI darwin builds ship unsigned

[justrach]

Problem

The release-binaries workflow triggers on release: published and uploads its own builds with --clobber. The local release flow (build → codesign → notarize with notarytool → upload) races against it: for v0.2.5825 the locally-notarized assets were published with the release, then overwritten ~3 minutes later by unsigned CI builds, and had to be re-uploaded by hand after the workflow finished.

Two compounding gaps:

1. The Apple signing secrets are not set in the repo (APPLE_CERTIFICATE_P12, APPLE_CERTIFICATE_PASSWORD, APPLE_CODESIGN_IDENTITY). The "Import Apple signing certificate" step is conditional on the secret and silently skips, so CI darwin-arm64 binaries are unsigned — directly contradicting the README support table ("✅ codesigned + notarized") whenever CI assets win the race.
2. CI cannot notarize at all — there is no notarytool step, and notarization needs an App Store Connect API key / keychain profile that only exists locally (notary-local).

Evidence (v0.2.5825, 2026-06-12)

• Run 27426667692: all four build jobs show - Import Apple signing certificate (skipped).
• Release assets after the run: codedb-darwin-arm64 had no Developer ID signature until manually re-clobbered with the notarized local build (sha 749e845a…, TeamIdentifier WWP9DLJ27P).
• checksums.sha256 from CI no longer matched the final asset set until regenerated locally.

Expected

One of:

• (a) CI is the single source of truth: add the signing secrets + a notarization step (App Store Connect API key as a secret, xcrun notarytool submit --wait), and the local flow is retired; or
• (b) Local is the single source of truth: the workflow skips asset upload when the release already has assets (or only uploads missing ones, no --clobber); or
• (c) The workflow becomes workflow_dispatch-only so publishing a release with pre-uploaded assets never triggers a clobber.

Fix

Decide (a)/(b)/(c) and amend .github/workflows/release-binaries.yml accordingly. (a) is the most robust; until the cert/API-key secrets are provisioned, (b) is a one-line guard: skip gh release upload --clobber when gh release view --json assets is non-empty.

Note: no failing zig test accompanies this issue — the defect is in the release pipeline, not the codebase. Reproduction evidence above stands in for it.