Add reusable Rust release workflows

[HDauven]

Summary

This PR adds reusable Rust release automation workflows for Dusk crates:

• rust-release-plan.yml creates or updates release-plz release PRs
• rust-release-check.yml validates release PRs and runs release/publish dry-runs
• rust-publish-crates.yml publishes through release-plz using crates.io trusted publishing

The publish flow uses OIDC trusted publishing directly through release-plz. It does not use CARGO_REGISTRY_TOKEN or rust-lang/crates-io-auth-action.

Release impact

This moves our Rust crate releases toward a release-plz owned flow:

• release changes are prepared through explicit release PRs
• version bumps, changelog entries, tags, GitHub releases and crates.io publishing are handled by release-plz
• caller repos declare the exact crates that are allowed to publish via publish-packages
• publish jobs validate the crate publish surface again immediately before publishing
• changelogs should no longer be edited manually for release entries

Caller repos should use a local .github/workflows/release-plz.yml workflow and configure crates.io trusted publishing with workflow filename release-plz.yml and environment crates-io.

Caller flow

A caller repo has one local release workflow entry point, usually .github/workflows/release-plz.yml.

That workflow exposes two manual commands:

• release-pr: creates or updates the release PR
• publish: publishes after the release PR has been reviewed and merged

The intended sequence is:

1. run release-pr
2. review the generated release PR
3. merge the release PR after checks pass
4. run publish

Publishing is intentionally manual after merge. The publish job uses the crates-io GitHub Environment, so repository or organization rules can require approval before crates.io receives the OIDC-backed publish.

Versioning

Version bumps are owned by release-plz.

When release-pr runs, release-plz compares the repo with the latest published crate version and uses merged commit history plus release-plz.toml to prepare the release PR. That PR contains the version bump and changelog updates.

For normal releases:

• do not manually bump crate versions
• do not manually edit release changelog entries
• use release-note-ready PR titles and descriptions
• prefer conventional titles such as feat(crate): ..., fix(crate): ..., docs(crate): ..., chore(crate): ...
• use ! or a BREAKING CHANGE: footer for breaking changes

After the release PR is merged, publish publishes the version already present on the default branch.'

For more details see release-plz

Registry setup required

Before using publish, configure crates.io trusted publishing for the particular crate:

• owner: dusk-network
• repository: REPO-NAME
• workflow filename: release-plz.yml
• environment: crates-io

[herr-seppia]

I got the rationale behind this, but I strongly believe that having the unreleased section compiled by contributors will help to understand what's in there, and help us in a lot of different situations (keep track of what's unreleased, know possible breaking changes that needs major bump, etc etc)

Instead of letting the files to be automatically generated, it would be useful (imho) to have CI to check what devs put in the CHANGELOG against what's supposed to be there (according to the CI), maybe adding some RFC to the PR

This will help in 2 ways:

• let the control of the CHANGELOG to developers
• help the developers in case of something missing or not coherent

[herr-seppia]

To be clear, I'm not against having it automatically generated. I'm against having it generated only when releasing it.

If it would be possible to autogenerate it while merging every single PR that would be awesome.

[HDauven]

I would need to look into that more. This release-plz flow is a fairly big change from how we do releases.

If we use their commit-based approach, we should not do tiny commits anymore because it would bloat generated changelogs.

If we want to do it based on PR titles/description, squash-merge would be the cleanest option.

We can also keep the old manual changelog approach though. I mostly care about the crate release/publishing side of release-plz. But let's discuss during the standup in the morning.

[xevisalle]

LGTM. I don't have a strong preference, but it looks good to me the current approach, it allows not having to update the same changelog twice if for instance for any reason we revert changes before release. I'm OK though if we end up following @herr-seppia 's suggestion.