[CI]: Add crates.io Cargo publish workflow for Rust-native plugins

[lucarlig]

Summary

Add release CI for Rust-native CPEX 0.2 plugins so each migrated plugin can be published to crates.io and consumed by ContextForge through the CPEX 0.2 path.

Parent epic:

• Convert managed plugins to Rust-native CPEX 0.2 plugins #61

Blocked By

This is blocked until the Rust-native plugin shape and CPEX 0.2 consumption path are stable enough to publish against:

• Convert managed plugins to Rust-native CPEX 0.2 plugins #61
• [CHORE]: Upgrade CPEX framework dependency to 0.2 mcp-context-forge#5249
• https://github.com/contextforge-org/cpex/releases

Scope

• Define crates.io crate naming for migrated plugins.
• Define release tag format for Rust-native plugin crate releases.
• Add CI jobs for Cargo publish dry-runs.
• Add release workflow for real crates.io publishing.
• Configure secure crates.io token usage or trusted publishing if available.
• Ensure each migrated plugin crate has complete crates.io metadata.
• Add checks that prevent publishing from non-main branches or mismatched tags.
• Add downstream resolution check proving ContextForge can import/resolve the published crates correctly.

Proposed Workflow

• Plugin migration PR updates crate metadata and version.
• CI runs fmt, clippy, tests, audit/deny checks, and cargo publish --dry-run for the changed plugin crate.
• A release tag for a plugin version triggers the publish workflow.
• Publish workflow verifies the tag points at main, validates crate metadata/version, runs final dry-run, then publishes to crates.io.
• A follow-up compatibility check verifies the published crate can be resolved by a minimal CPEX 0.2/ContextForge consumer.

Open Questions

• Should crate names keep the current underscore crate names or use cpex-* names on crates.io?
• Should all plugins publish independently or through a coordinated workspace release?
• Should pre-1.0 plugin versions reset for the Rust-native line or continue from current package versions?
• Should PyPI package versions and crates.io versions stay aligned during transition?
• Should release tags use existing plugin slug tags or a new Cargo-specific pattern?

Acceptance Criteria

• crates.io naming and versioning policy is documented.
• Rust-native plugin crates have required metadata for crates.io publishing.
• CI runs cargo publish --dry-run for publishable plugin crates.
• Release workflow can publish an individual plugin crate to crates.io from an approved tag on main.
• Publishing secrets/credentials are configured securely.
• Workflow fails clearly on version/tag mismatch, missing metadata, or non-main tag target.
• ContextForge/CPEX downstream dependency resolution is validated for a published or dry-run equivalent plugin crate.