feat: add cargo publish reusable workflow

[bshek-xitaso]

Note: A new tag should be created after the merge.

This PR addresses #18.

It adds a reusable workflow for publishing Rust packages to crates.io.

The optional environment input preserves the release environment used by vers-rs, while callers without an environment can omit it.

[Copilot]

Pull request overview

Adds a reusable GitHub Actions workflow for publishing Rust crates to crates.io with optional environment protection.

Changes:

• Adds OIDC-based crates.io authentication.
• Supports optional GitHub environments.
• Publishes locked Rust packages with submodules enabled.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[peinjoh]

Please pin the two used actions

[peinjoh]

Could you add some more in-code documentation when to use/not to use the environment arg?

Also, similarly to the dry-run, please document how the selection of packages works in our repos, i.e. we run on workspace and explicitly disable via cargo.toml publish=false

[peinjoh]

This is something we should discuss generally here: Do we want to allow concurrency of this job per repo? I can think of some misconfig / rerun situations were we end up with concurrently running publish of the same package, which might cause wierd results / race conditions.

We can also discuss add this later, slightly out of scope. Opinions?

[bshek-xitaso]

I added a repo-specific concurrency group (Code) as well as a "cargo publish --dry-run"-step for checking the publishability (Code).

About the possible permission minimization: crates-io-auth-action needs a JWT from GitHub to authenticate with crates.io (Link), and GitHub docs states that requesting this JWT requires id-token: write permission (Link). So, I think the permissions are already minimal.