Add crates.io publishing infrastructure for public reusable crates

[jmagar]

Goal

Prepare rmcp-template's Rust release/build tooling for multiple public crates instead of a single template component.

This is the Rust crate publication infrastructure issue. It should stay standalone from release-please workflow adoption (#72) and Node/npm distribution (#73), while providing the Rust crate metadata and package checks those issues may consume.

Scope

This issue covers shared crates.io publishing infrastructure, not the implementation of any one crate and not npm/npx distribution. It should support future publication of auth, codemode, traces, contracts-core, gateway/proxy/server crates, and any Rust facade package.

Required capabilities

• Independent release components per public Rust crate.
• Crate metadata checks for repository, readme/docs, license, keywords/categories, and publish policy.
• cargo package / dry-run publish gates.
• Consumer fixture tests proving each public crate works outside product runtime crates.
• Changelog/version sync that can handle multiple Rust crates without forcing every push to bump every crate.
• CI gates that distinguish docs/template-only changes from public crate changes.

Alignment with related issues

• Implement release-please across template release surfaces #72 owns release-please workflow adoption across ecosystems. This issue should expose Rust crate metadata/version inputs that release-please can bump or validate.
• Create Node distribution package with npx MCP launch support #73 owns npm/npx distribution. This issue should not package Node launchers, but it may provide Rust binaries/crates that npm wrappers consume.
• Any release manifest changes must keep release/components.toml and release-please manifests aligned until one source of truth is chosen.

Non-goals

• Do not implement release-please configuration here except where needed to keep Rust crate metadata compatible with Implement release-please across template release surfaces #72.
• Do not implement npm package layout or npx launch behavior here.
• Do not publish auth/codemode/traces/etc. before their crate boundaries are stable.

Acceptance criteria

• Extend release component model beyond the current single template component for Rust crates.
• Add or update xtask checks for crate metadata and package dry runs.
• Add guidance for public crate naming/versioning and workspace dependency policies.
• Add CI jobs or just targets for cargo package checks on public crates.
• Document the publication workflow, including what remains unpublished/private.
• Document handoff points to Implement release-please across template release surfaces #72 and Create Node distribution package with npx MCP launch support #73 so release automation and npm packaging consume the same version/component model instead of inventing parallel metadata.

Sources

• /home/jmagar/workspace/rmcp-template/release/components.toml:1 — current single-component release configuration.
• /home/jmagar/workspace/rmcp-template/docs/adr/0008-versioning-and-distribution.md:47 — release manifest is the source of truth and public publishing waits for stable boundaries.
• /home/jmagar/workspace/rmcp-template/crates/rtemplate-contracts/Cargo.toml:1 — example of current crate with publish = false/thin public metadata.
• /home/jmagar/workspace/lab/crates/labby-auth/Cargo.toml:1 — Lab donor crates currently set publish = false.

Implementation sequence

1. Audit current Rust crate publication state.

   • Identify which crates are template-only, publishable candidates, or internal support crates.
   • Verify publish = false, metadata completeness, dependency graph, and release component ownership.

2. Extend release component modeling.

   • Add independent Rust crate components where appropriate.
   • Ensure component versioning can coexist with release-please manifests from Implement release-please across template release surfaces #72.
   • Define how unpublished/private crates are represented without accidental publish attempts.

3. Add package validation.

   • Add xtask/CI checks for crate metadata, cargo package, workspace dependency policies, and consumer fixtures.
   • Make package dry-runs path-aware so docs/template-only changes do not run unnecessary publication gates.

4. Document publishing workflow.

   • Document crates.io token expectations, dry-run flow, publish order, rollback/yank guidance, and what remains unpublished.

Local files likely touched

• release/components.toml
• root Cargo.toml and Cargo.lock
• crate Cargo.toml files under crates/*
• xtask/src/*version*, xtask/src/*release*, or new package-check commands
• .github/workflows/*
• docs/*release*, docs/*publishing*, or ADRs
• consumer fixture/test crates

Risks

• Accidentally publishing template-specific crates or internal support crates.
• Version drift between release/components.toml, Cargo metadata, and release-please manifests from Implement release-please across template release surfaces #72.
• Public crates gaining dependencies on product/runtime crates, making them unusable outside the template.
• CI package checks becoming too expensive unless path-gated.