fix(ci): drop registry-url from setup-node so OIDC trusted publishing works

[ylabonte]

Summary

The release.yml run that fired on the PR #14 (1.1.0) merge failed inside changesets/action's pnpm release step (run 25931442199). This was the first publish attempt under pure OIDC trusted publishing — PR #11 removed the bootstrap NPM_TOKEN after 1.0.0 landed, and 1.0.0 itself published via that token, so this is the first OIDC publish path we've actually exercised.

Root cause

actions/setup-node, when given registry-url:, writes an .npmrc containing:

//registry.npmjs.org/:_authToken=${NODE_AUTH_TOKEN}

npm 11 reads that, sees a configured _authToken, and uses it instead of running the OIDC exchange. We deliberately don't set NODE_AUTH_TOKEN (we want OIDC), so the resulting credential is empty/garbage and npm publish 4xx's. That bubbles up as The process '/home/runner/setup-pnpm/node_modules/.bin/pnpm' failed with exit code 1, which is exactly what the failed run shows.

npm's trusted-publishing flow only triggers when no token is configured at all. The fix is to stop having setup-node write a token entry — i.e. drop registry-url:. The default registry is registry.npmjs.org, so the option was decorative anyway.

References:

• https://github.com/orgs/community/discussions/176761 ("setup-node has a default token; clearing it makes OIDC work")
• https://docs.npmjs.com/trusted-publishers/

What changes

• .github/workflows/release.yml: remove registry-url: https://registry.npmjs.org from the actions/setup-node step. Add a comment block on top of the step so the next person reaching for registry-url: knows why it's deliberately absent.

Out of scope (deliberately)

The failed run also surfaced an app-id deprecation warning from actions/create-github-app-token@v3 (use client-id instead). That's a warning, not the failure, and the App's Client ID is a different value from its numeric App ID — flipping the input without rotating the RELEASE_APP_ID secret to a RELEASE_APP_CLIENT_ID would silently mint a broken token. Worth a follow-up issue / PR with coordinated secret rotation; not bundled here.

No changeset: CI-only workflow change, no user-visible behavior.

Test plan

• Merge this PR.
• On the resulting push to main, release.yml fires. No changesets remain (1.1.0 was already versioned and merged), so changesets/action falls straight through to pnpm release. Expect: trusted-publisher OIDC exchange succeeds, github-actions-updater@1.1.0 lands on npm with provenance, the floating v1 tag is force-moved to the new commit.
• If publish still fails, the failure mode will be different (likely an npm-side trusted-publisher misconfiguration: workflow / environment / repo mismatch on npmjs.org), which narrows the investigation to npm-side config rather than workflow-side config.

Note on idempotency: if 1.1.0 was already published to npm during an earlier attempt (it wasn't, per the failed run), npm publish will return 403 on a re-run. That'd require either a 1.1.1 patch bump or npm unpublish within the 72h window.

---

Generated by Claude Code