ci: unify varlock CLI binary release into the main release workflow

[theoephraim]

Why

Today the native binaries get built + signed + notarized twice: once in release.yaml (for the npm package) and again in binary-release.yaml (triggered by the GitHub release, for the SEA/CLI binaries). The second run was the source of the tag-subject OIDC failures, re-notarization, and the partial-release window we just worked through.

What

Build + sign + notarize once, reuse everywhere.

• release.yaml — the release job already stages the signed/notarized native-bins (for npm). It now also uploads them as a native-bins-staged artifact (one step, after the bumpy publish, so npm publish is never gated on it). Two new plan-gated jobs consume that artifact:

  • release-binaries: build SEA binaries → upload to the varlock@<version> release bumpy created → update homebrew tap
  • release-docker: build + push the Docker image

  These run on a single ubuntu runner with no macOS/Windows runner, no Azure, no Apple — so the tag-subject OIDC problem is gone by construction.

• binary-release.yaml — drops the release: published trigger and the three native-build jobs. It's now a manual workflow_dispatch re-cut path that pulls the signed native binaries from the published npm package (varlock's files includes /native-bins) for re-cutting an existing version.

This is also the first concrete sketch of the "release targets" model we discussed (binaries / homebrew / docker as discrete, plan-gated jobs consuming a built-once artifact) — the build plane (native binaries) feeding the publish plane.

Review / rollout notes

• Critical path; only fully testable by a real release. The npm publish itself is unchanged except for one trailing artifact-upload step. If the new jobs fail, npm is already published and you can recover via the manual binary-release dispatch.
• Worth a careful read of the release-binaries job (version resolution, the GH release upload target, homebrew env) before merging.
• After this merges, the next varlock release exercises it end-to-end; the varlock@* tag federated credential is no longer needed (nothing signs on the tag path).