Evaluate cargo-release and maturin publish for plugin releases

[lucarlig]

Problem

CPEX plugin releases currently use a custom per-plugin flow:

• manually update Cargo.toml, plugin-manifest.yaml, and Cargo.lock
• merge the version bump to main
• manually create a <hyphenated-slug>-v<version> tag
• run .github/workflows/release-rust-python-package.yaml
• build with maturin build / maturin sdist
• publish collected artifacts through pypa/gh-action-pypi-publish

This works, but the repo now owns release mechanics that standard tools may already cover.

Related issue: #82 tracks automating release tag creation in the current workflow. This issue is not a duplicate unless we decide that #82 should also own the release toolchain decision.

Proposal

Evaluate whether plugin release and publish should move to a standard toolchain based on:

• cargo-release for version bumping, consistency checks, commits, and tag creation
• maturin publish for building and publishing Rust-backed Python packages

The goal is to reduce custom release logic while preserving the CPEX-specific constraints around managed plugin discovery, tag naming, plugin manifests, CI checks, and PyPI trusted publishing.

Questions to answer

• Can cargo-release support the required per-plugin tag format, for example rate-limiter-v0.0.5?
• Can cargo-release safely update only the target plugin crate in this monorepo/workspace?
• How should plugin-manifest.yaml stay in sync with the Cargo version?
• Should manifest sync be handled by cargo-release hooks, an existing repo validation script, or a small dedicated helper?
• Can maturin publish replace the current build plus pypa/gh-action-pypi-publish publish job while keeping OIDC/trusted publishing?
• Does maturin publish fit the current multi-platform wheel matrix, or should publishing remain a separate artifact aggregation step?
• How does this interact with Automate Rust plugin release tags #82's automated tag creation path?

Suggested implementation path

1. Prototype on one plugin, likely rate_limiter, without changing the release process yet.
2. Add or document a cargo-release config that encodes the required tag format and per-plugin behavior.
3. Decide whether version sync for plugin-manifest.yaml needs a repo helper.
4. Test a dry-run release path in CI or locally:
   • no unintended workspace-wide version bumps
   • correct tag name
   • correct Cargo.lock update
   • manifest version stays aligned
5. Evaluate maturin publish against the current wheel build matrix and PyPI/TestPyPI publishing requirements.
6. If viable, update release workflow and DEVELOPING.md; otherwise document why the current custom workflow is preferred.

Acceptance criteria

• A documented decision exists: adopt cargo-release / maturin publish, partially adopt them, or keep the current workflow.
• The decision explicitly covers tag naming, monorepo/per-plugin behavior, manifest version sync, Cargo.lock, and PyPI/TestPyPI publishing.
• If adopted, CI release workflow and maintainer docs are updated.
• If not adopted, the repo documents the blocker so future release automation work does not re-investigate the same path.
• Relationship with Automate Rust plugin release tags #82 is clarified, either by updating Automate Rust plugin release tags #82 or closing one issue as superseded.