ci(publish): pin npm to 11.x so the publish job works on Node 20

[SanabriaRusso]

Closes #206.

Problem

The v0.0.9 tag push failed at the Update npm step — run 30540591005 — before dependencies were installed, before tests, and before npm publish:

npm error code EBADENGINE
npm error Not compatible with your version of node/npm: npm@12.0.2
npm error notsup Required: {"node":"^22.22.2 || ^24.15.0 || >=26.0.0"}
npm error notsup Actual:   {"npm":"10.8.2","node":"v20.20.2"}

npm@latest has moved to 12.0.2, which dropped Node 20. The job pins node-version: '20', so the install is refused. Nothing was published — npm still shows only 0.0.6.

This is an upstream change, not a repo regression: it breaks any tag pushed from today onward.

Change

-      # Ensure npm 11.5.1 or later is installed
       - name: Update npm
-        run: npm install -g npm@latest
+        run: npm install -g npm@11

npm@11 is currently 11.19.0, engines ^20.17.0 || >=22.9.0 — satisfied by the job's Node 20.20.2, and well past the 11.5.1 that trusted publishing / OIDC requires. Pinning the major keeps patch updates flowing without another silent engine break; the unqualified latest is what made this a time bomb.

Why not bump Node to 22

More future-proof, but wider: the publish job also runs the full npm test, so changing its Node version changes the runtime the release is validated against. #194 (P1: Upgrade to graphql-yoga 5 and Node 22 LTS) is already open and is the right place for that. Once it lands, this pin can be revisited.

Verification

This workflow only runs on v* tag pushes and workflow_dispatch, so PR CI cannot exercise it. The engine claim is checked directly against the registry:

$ npm view npm@11 version   ->  11.19.0
$ npm view npm@11 engines   ->  { node: '^20.17.0 || >=22.9.0' }
$ npm view npm@12 engines   ->  { node: '^22.22.2 || ^24.15.0 || >=26.0.0' }

Node 20.20.2 satisfies ^20.17.0 and does not satisfy ^22.22.2, which is exactly the observed pass/fail split. Real proof comes from the retriggered v0.0.9 publish after this merges.

Follow-up

v0.0.9 is tagged at 3d254f7 but published nothing. Re-running the failed run will not help — a tag-push event uses the workflow file as it exists at the tagged commit, which still has the broken step. The tag needs to be moved to the commit containing this fix and re-pushed. Since no npm version was consumed, that is a clean operation.

🤖 Generated with Claude Code