ci: reuse cached signed/notarized native binaries on release

[theoephraim]

Problem

The release workflow rebuilt and re-notarized the macOS / Rust native encryption binaries on every publish, even when nothing under the native source changed. The three native jobs were gated only on mode == 'publish' && includes-varlock == 'true' — never on whether the binary-relevant source actually changed.

The Apple notarization round-trip (xcrun notarytool submit --wait) is the worst offender: it's slow, externally dependent, and occasionally flaky, and re-running it for a byte-identical binary is pure waste.

What this does

Gates the build-native-macos, notarize-native-macos, and build-native-rust jobs on a content-addressed cache probe in the plan job. On a cache hit, the build + notarize jobs are skipped and the previously notarized bundle / Rust binaries are reused.

• Cache key = content hash of the native source + build/bundle scripts + the workflows that drive them, plus a manual v1 salt to force a fleet-wide rebuild on toolchain bumps the file hash can't see (runner image / Xcode / Rust / UPX).
• No git diff change-detection — that's empty on main. The cache key is the change detector.
• The macOS .app is already version-independent in CI (the release path doesn't pass --version, so the bundle embeds a constant placeholder, not the npm version), which is what makes the notarized bundle byte-stable across releases. Documented inline.

"Never publish the wrong thing" safeguards

This was the explicit design constraint. Layers:

1. Content-addressed keys — a restored binary always corresponds to the source that produced it.
2. Cache scope — a release on main can only restore caches produced by prior main runs; feature-branch caches aren't visible. Combined with branch protection, that's the anti-poisoning boundary.
3. Re-verification before publish — a reused macOS bundle is re-validated on a macOS runner (codesign --verify --deep --strict + xcrun stapler validate + a functional status smoke) in a new verify-native-macos job. If it can't be verified, the release is blocked (!failure()).
4. Fail-loud presence check — the publish job aborts if any native binary is missing before building the npm package.
5. fail-on-cache-miss: true on the publish-side restores, so a mid-run eviction blocks rather than silently shipping an incomplete package.

Rollout

The first release after this lands sees no cache under the new v1 keys, so it rebuilds + notarizes once to seed the cache. Subsequent releases with unchanged native source reuse it (skipping the macOS build + the Apple notarization round-trip, and the Rust matrix).

Compatibility

• notarize-native-macos.yaml gains an optional cache-key input (default empty); all caching steps are gated on it being set. The other caller (binary-release.yaml) doesn't pass it and is unaffected.
• build-native-rust.yaml is unchanged — the release path just passes a salted, comprehensive source-hash into the existing source-hash input.

Notes / caveats for review

• The reused-bundle reverification is the key thing to scrutinize: it relies on the .app round-tripping through actions/cache with its signature + stapled ticket intact. Those are regular files in the bundle (not xattrs), and test.yaml already round-trips the signed .app through cache today, so the path is exercised — but the verify-native-macos job exists precisely to catch it if a future cache/runner change breaks it.
• No changeset added — this is a CI-workflow-only change, which per AGENTS.md does not require a bump file.
• Not runnable locally; correctness needs to be observed on the first real release (watch that it seeds the cache, and the one after reuses + verifies).