feat(release): add unified release workflow with release-plz

[gustavovalverde]

Motivation

Zebra releases currently follow a 51-item manual checklist taking 4-8 hours, blocking the team via Mergify queue freeze. Publishing uses personal API tokens, and changelogs are manually curated with a known race condition in Release Drafter.

Solution

Add a release-plz pipeline that automates crate publishing and GitHub Release creation.

Release chain

push to main → release.yml
  ├── release-pr (creates/updates Release PR with version bumps + changelogs)
  └── release (publishes crates via trusted publishing + creates GitHub Release)
                    ↓ fires release:released event
release-binaries.yml (existing, unchanged) → Docker Hub
                    ↓ fires release:published event
zfnd-deploy-nodes-gcp.yml (existing, unchanged) → GCP deployment

The release job exits early for non-Release-PR commits (release_always = false). release-binaries.yml stays unchanged — it triggers on the release:released event that release-plz creates.

What this replaces

• release-drafter.yml → release-plz + git-cliff generate changelogs
• The 51-item manual checklist → automated with human gate (Release PR review)

Verified locally

release-plz update correctly detects all 12 crates, compares against crates.io, bumps versions from conventional commits, and generates per-crate changelogs.

Tests

The workflow activates on merge to main. Until trusted publishing is configured on crates.io, the release job will succeed but skip crate publishing.

AI Disclosure

• AI tools were used: Claude for release-plz source code analysis, cliff.toml template debugging, and workflow design.

PR Checklist

• The PR title follows conventional commits format: type(scope): description
• The PR follows the contribution guidelines.
• This change was discussed with the team beforehand.
• The solution is tested.
• The documentation and changelogs are up to date.

[mpguerra]

Had a quick glance, looks good but didn't reason about it in detail.

Not sure if this should be added to the release workflow but we should find some way to publish the EOS height for zebra (possibly with an estimated EOS date based on height) somewhere visible for end users similar to what is done for zcashd.

[gustavovalverde]

@mpguerra the initial work for the EOS date is in the following PR #10459

[conradoplg]

I'm a bit wary of using release-plz because I had problems with it when I tried. I think it was something like, if it stops in the middle for whatever reason (internet disconnect, etc.) you have to resume it manually. IIRC I think I had problems where a tag was created but the crate was not published, and when trying again it would refuse to publish because the tag already existed, or something similar.

This also does not fully capture our workflow. We use cargo public-api to list API changes to put in the changelog, cargo semver-checks just tells if a major bump is required or not (and can't distinguish between minor and patch releases).

That being said we can try this, just need to be aware of the possible issues.