ci: publish the MCP npm packages from mcp-npm-v tags

[suchintan]

Releases are cut from tags on this repository, but the MCP npm publish workflow was missing here — an mcp-npm-v* tag currently publishes nothing. This adds it, including the same dist-tag selection release-npm.yml uses (prerelease tags publish as next, stable as latest), so a prerelease can never take over latest.

The workflow's inputs (mcp/npm/targets.json, mcp/npm/scripts/build-npm.mjs, mcp/Cargo.toml) are all present in this repository, and NPM_TOKEN is the same secret release-npm.yml already publishes with.

🤖 Generated with Claude Code

[claude]

Summary

Clean, well-scoped CI-only addition — a new release-mcp-npm.yml that mirrors the existing release-npm.yml pattern (metadata validation → per-target matrix build with zigbuild cross-compilation → provenance-signed publish with dist-tag selection). No Rust/Python/Node source changes, so most of the FFI/CDP/API review checklist doesn't apply here. Two gaps versus the sibling release workflows are worth closing before this goes live.

🔴 Critical Issues (0)

None.

🟡 Suggestions (2)

• Publish job is missing the repo guard every other release workflow has. release-gem.yml, release-maven.yml, release-npm.yml, release-nuget.yml, and release-pypi.yml all gate their publish job with if: github.repository == 'Skyvern-AI/rustwright' && github.ref_type == 'tag' && (...). This new workflow's publish job (lines 128–184) has no such guard — it runs unconditionally once build succeeds. If this repo is ever forked and a fork owner (with their own NPM_TOKEN configured under the npm environment) pushes a mcp-npm-v* tag, this would attempt a real publish with no repository check to stop it. Worth adding the same guard for defense-in-depth consistency.
• No workflow_dispatch + dry_run escape hatch. Every sibling release workflow accepts a workflow_dispatch input with a dry_run boolean so the build/package steps can be exercised without actually publishing. This workflow only triggers on push: tags: mcp-npm-v*, so the only way to test it end-to-end is to push a real tag — which, combined with the missing guard above, immediately attempts a real npm publish. Consider adding the same dry_run pattern used elsewhere.

📝 Minor / Style (2)

• taiki-e/install-action is pinned to 2ca9b94c... (# v2.83.1, line 85) here but to a different, newer SHA (# v2.84.0) in release-npm.yml. Not a bug, but worth aligning to one pinned version across workflows.
• Rust setup uses raw rustup toolchain install 1.95.0 --profile minimal --target ... + cargo +1.95.0 ... instead of the dtolnay/rust-toolchain@<sha> # stable action every other workflow (release-npm.yml, release-gem.yml, release-maven.yml, release-nuget.yml, test.yml, fingerprint.yml, ...) uses. Pinning an exact patch version does buy reproducibility across the 5 release targets, which is a reasonable tradeoff, but it's a style/tooling divergence from the rest of the repo and means someone has to remember to bump 1.95.0 by hand over time — worth a one-line comment on why it's pinned this way, or switching to the shared action for consistency.