ci: unblock changesets publish from npm's devEngines check

[kraenhansen]

Fixes the failing Release job in run 31467628286 (and the identical failure on the Version Packages (#393) merge, run 31466790389).

The failure

🦋  info npm info @react-native-node-api/cli-utils
…
🦋  error Received an unknown error code: EBADDEVENGINES for npm info "@react-native-node-api/cli-utils"
🦋  error The developer of this package has specified the following through devEngines
🦋  error Invalid devEngines.packageManager
🦋  error Invalid name "pnpm" does not match "npm" for "packageManager"

changeset publish shells out to npm info <pkg> --json to work out which versions are already on the registry — changesets 2.x always uses npm for this, there is no pnpm code path. npm ≥ 11 validates the root package.json's devEngines in BaseCommand#checkDevEngines, i.e. on every command including info, so it exits 1 with EBADDEVENGINES because we declare devEngines.packageManager: pnpm and the process running is npm.

This is why the publish only broke now: the Release job only runs the publish command once the Version Packages PR has been merged, and the last actual publish was on 2026-01-05. All packages on npm are currently behind the repo (react-native-node-api 1.0.1 vs 1.1.0, cmake-rn 0.6.3 vs 0.7.0, ferric-cli 0.3.11 vs 0.4.0, …), so releases are blocked until this lands.

The fix

Set npm_config_force: true on the changesets step. npm's checkDevEngines downgrades devEngines errors to warnings when force is set, which is the only supported escape hatch — --ignore-dev-engines is not a thing in npm 11 (it warns Unknown cli config "--ignore-dev-engines" and still errors).

Verified locally against the repo root with Node 24 / npm 11.17:

$ npm info react-native-node-api --json; echo $?
npm error code EBADDEVENGINES
… 1
$ npm_config_force=true npm info react-native-node-api --json > /dev/null; echo $?
npm warn EBADDEVENGINES …   # stderr only, JSON on stdout is unaffected
0

Deliberately scoped to that one step rather than the workflow (so pnpm install above is untouched) and rather than relaxing devEngines in package.json (which would weaken the guard for everyone locally). Publishing itself is not affected by force: changesets detects the pnpm lockfile and uploads via pnpm publish, and pnpm publish ignores the npm force config.

Why not upgrade changesets instead

Changesets v3 does fix the root cause properly — its publish pipeline is package-manager-aware and runs pnpm info / pnpm pack / pnpm publish when pnpm is detected, so npm is never invoked. But it isn't reachable yet:

• @changesets/cli v3 exists only as a prerelease (next = 3.0.0-next.12); latest is still 2.31.1, whose shipped dist spawns bare npm info.
• It can't be upgraded on its own. v3 dropped the New tag: <pkg>@<version> stdout line that changesets/action@v1 parses; the action's v2 line instead has the CLI write NDJSON git-tag events to $CHANGESETS_OUTPUT and reads that file. CLI v3 with action v1 would publish but report published: false and push no git tags or GitHub releases — a silent regression rather than a loud one.
• changesets/action v2 is prerelease-only too (v2.0.0-next.4, latest stable v1.9.0) and renames every input to kebab-case, so this step would become publish-script: plus a github-token: input.

So that migration is two coordinated prerelease majors on the release pipeline itself, and it's worth its own PR. The workflow comment records it as the removal condition for this workaround.

Heads-up, not addressed here

NPM_TOKEN was dropped from this step in 3690bd1 ("Update release to use the main environment") and nothing has been published since 2026-01-05, so the auth side of the publish is untested. If npm trusted publishing is not set up for these packages, the next failure will be an auth error and the step will need either NPM_TOKEN mapped back in from the main environment or permissions: id-token: write on the job. I left that alone since I can't see the environment's secrets or the npm-side configuration — let me know which it should be and I'll follow up.