ci(release): publish Rust crates to crates.io from the release tag

[suchintan]

https://github.com/Skyvern-AI/rustwright-cloud/pull/249

[claude]

Summary

This is a CI/release-tooling PR only (synced from rustwright-cloud) — it doesn't touch the Rust engine, FFI boundaries, CDP layer, or the Python/Node surface, so most of the risk areas for this repo don't apply here. The new release-crates.yml workflow correctly mirrors the existing PyPI/npm/NuGet release pattern (SHA-pinned actions, OIDC Trusted Publishing, environment-gated manual approval, idempotent "skip if already published" check), and the rust-native/README.md fix corrects an example that didn't actually compile against the real GotoOptions/ActionOptions signatures. One real gap below in how the new validator script is wired up.

🔴 Critical Issues (0)

None found.

🟡 Suggestions (2)

• tools/check_crate_release.py's docstring says "The test workflow runs this on every pull request", but it is only invoked from release-crates.yml (tag push / manual dispatch) — test.yml, the workflow that actually runs on every PR, never calls it. So a version-mismatch between Cargo.toml and rust-native/Cargo.toml's rustwright_core dependency requirement still won't be caught until tag time, which is the exact problem this script's docstring claims it solves. Either wire the check into test.yml (cheap, no Rust/network needed) so drift is caught at PR time as intended, or fix the comment so it doesn't overstate the coverage.
• The root Cargo.toml was tightened this PR to include = ["/src/**/*.rs", "/README.md", "/LICENSE"] so the crates.io package ships only engine sources, but rust-native/Cargo.toml has no equivalent include/exclude — it'll publish its full tracked tree (examples/, tests/, src/bin/runner.rs) to crates.io. Not a correctness bug (everything there builds fine with declared deps), just an inconsistency in scoping intent between the two newly-published crates; worth a quick pass if the goal was a lean published package.

📝 Minor / Style (1)

• check_crate_release.py compares the facade's rustwright_core dependency requirement string to the core's version with plain string equality. That only works today because the requirement happens to be pinned to the literal "0.3.0"; a perfectly valid future edit like version = "^0.3.0" would fail this check even though it's compatible. Not a problem now, just brittle if the requirement is ever loosened.