Release: crates.io is not part of the tagged release, so the Rust crates lag every other registry

Summary

The v* release tag drives five publish workflows — PyPI, npm, RubyGems, NuGet, and Maven Central — but there is no workflow that publishes the Rust crates. grep -r "cargo publish\|CARGO_REGISTRY_TOKEN" .github/ returns nothing.

The result after the 0.2.0 release:

Cargo.toml at the v0.2.0 tag already declares version = "0.2.0", so the crates are versioned for the release — they were simply never pushed.

Why this is worth fixing

This is a Rust project whose own crates are the thing most Rust users would reach for first, and the README carries crates.io download badges. Right now those badges advertise a version that is a full release behind the bindings. Anyone who finds the project through crates.io gets 0.1.1 and none of the 0.2.0 fixes — including the evaluate() statement-forms restoration.

It is also the only registry in the set that depends on someone remembering to run a command by hand, which is exactly the step that gets skipped.

Suggested fix

Add release-crates.yml alongside the other five, gated the same way (github.ref_type == 'tag', publish only on a tag push or a non-dry-run dispatch), publishing rustwright-core first and then rustwright, since the latter depends on the former and crates.io needs the dependency to be live before the dependent will verify.

Worth handling explicitly in that workflow:

• crates.io publishes are permanent — a version can be yanked but never replaced — so the dry-run path should use cargo publish --dry-run and the real path should run only from a tag.
• The two crates need an ordered publish with a wait, because the index takes a short while to expose a freshly published version to the dependent crate's resolver.

Immediate state

0.2.0 is published everywhere else. The crates can be pushed for 0.2.0 without any version bump, since the manifest is already at 0.2.0.

Start by inspecting the five existing registry publish workflows under .github/ and the crate definitions in Cargo.toml. Compare their tag and dispatch gates, then verify the two-crate dependency order and dry-run behavior with cargo publish --dry-run. Done means both 0.2.0 crates publish from a tag, with rustwright-core available before rustwright.