fix(ci): use npm trusted publishing via OIDC on Node 24

[m-abdelwahab]

Summary

Fixes the Publish NPM job, which has been silently failing since v4.37.0. npm is currently stuck on 4.36.1 while GitHub releases and crates.io have shipped 4.37.0 → 4.37.2.

• Bump runner to Node 24 (bundles npm 11.x → trusted publishing works)
• Drop --provenance (automatic under trusted publishing)
• Bump actions/setup-node v4 → v6 (v4 runs on Node 20 internally, which GitHub is deprecating)

Root cause

The last three releases failed on the same npm publish step with a misleading error:

npm error 404 Not Found - PUT https://registry.npmjs.org/@railway%2fcli
npm error 404 '@railway/cli@4.37.2' is not in this registry.

The package is in the registry — the 404 is what npm returns for a scoped package when auth is missing. Trusted publishing is configured on npmjs.com correctly, but npm 10 (bundled with Node 22) doesn't support trusted publishing for registry auth:

Feature	Needs	Node 22 / npm 10
Provenance signing (--provenance)	npm ≥ 9.5.0	✅
Trusted publishing auth	npm ≥ 11.5.1	❌

That's why the failed log shows Signed provenance statement... succeeding (OIDC → Sigstore worked) immediately before the 404 on the actual upload (no OIDC → registry). With no NODE_AUTH_TOKEN secret in the repo, npm fell through to an anonymous PUT.

Failing run: https://github.com/railwayapp/cli/actions/runs/24256202033/job/70829420403

Why Node 24, not an npm install -g step

#838 removed npm install -g npm@latest after it started cross-major-upgrading npm 10 → 11 on the runner and corrupting itself mid-install (npm removes its own node_modules dependencies like promise-retry while replacing them). The PR description there claimed Node 22 + npm 10 was sufficient because "npm has had OIDC/provenance support since 9.5.0" — but that conflated provenance signing (npm ≥ 9.5.0) with trusted publishing auth (npm ≥ 11.5.1).

Node 24 LTS bundles npm 11.x directly, so no self-upgrade is needed — avoiding both the auth issue and the corruption risk #838 was working around.

What about --provenance?

Trusted publishing attaches provenance attestations automatically, so the flag is redundant. Leaving it in would work but is noise.

Release strategy

This PR ships with release/skip — it's a CI-only change with no user-facing code impact, so it doesn't warrant its own version bump. The trusted-publishing flow will be validated by the next real patch/feature PR that carries a release/patch label. When that PR cuts v4.37.3, the release will:

• Publish the accumulated 4.37.0–4.37.2 changes to npm for the first time (closing the current gap)
• Exercise the new trusted-publishing workflow end-to-end with provenance attestations

npm will jump from 4.36.1 → 4.37.3, skipping the stranded 4.37.0–4.37.2 tags on npm. That's safe: nothing on npm pins those versions (they were never published there), npm install -g @railway/cli always resolves to @latest, and the feature content accumulated in those tags will all land on npm when 4.37.3 publishes.

Test plan

• Merge this PR (with release/skip)
• Open follow-up PR with a real change + release/patch label
• On merge, confirm the Publish NPM job succeeds
• Confirm npm view @railway/cli@4.37.3 shows dist.attestations populated (provenance attached automatically via trusted publishing)
• Confirm npm install -g @railway/cli installs 4.37.3 and runs

References

• npm trusted publishing docs
• GitHub changelog: npm trusted publishing OIDC GA (2025-07-31)
• Supersedes fix: remove npm self-upgrade step that breaks release CI #838

🤖 Generated with Claude Code