ci: publish on Node 24 with a pinned npm

[JohnMcLear]

.github/workflows/npmpublish.yml ran the publish job on Node 25 and then
did npm install -g npm@latest. npm 12 requires
^22.22.2 || ^24.15.0 || >=26.0.0 — Node 25 is excluded — so that step died
with EBADENGINE and the package could never be published:

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

Move the job to Node 24 (an LTS line supported by every npm 11.x and 12.x)
and pin the upgrade to npm@^11.5.1 — a range rather than @latest, so the
next npm major dropping this Node line can't silently break publishing
fleet-wide again. >=11.5.1 is what OIDC trusted publishing needs.

Same fix as ether/ep_align#227.

🤖 Generated with Claude Code

https://claude.ai/code/session_013S4pYSjwUsiZtdtMMpW7bw

[qodo-code-review]

ⓘ Qodo reviews are paused because the subscription is no longer active. Ask your workspace admin to reactivate the subscription to resume reviews. Manage billing

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (1) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Publishing has no regression test 📘 Rule violation ▣ Testability

Description

The workflow changes the publish runtime and npm version range without adding or updating an
automated test for the previously failing publish path. A future Node or npm compatibility change
can therefore reintroduce the EBADENGINE failure without a test detecting it before publishing is
blocked.

Code

.github/workflows/npmpublish.yml[R23-33]

+          # OIDC trusted publishing needs npm >= 11.5.1. Node 24 is an LTS
+          # line that every npm 11.x and 12.x supports; Node 25 is not —
+          # npm 12 requires ^22.22.2 || ^24.15.0 || >=26.0.0, so on Node 25
+          # the upgrade step below died with EBADENGINE and no plugin could
+          # publish.
+          node-version: 24
         registry-url: https://registry.npmjs.org/
+        # Pinned to a range rather than @latest: the next npm major dropping
+        # this Node line would silently break publishing fleet-wide again.
     - name: Upgrade npm to >=11.5.1 (required for trusted publishing)
-        run: npm install -g npm@latest
+        run: npm install -g npm@^11.5.1

Evidence

The PR description and commit message explicitly identify this change as a bug fix for an
EBADENGINE failure that prevented publishing. The changed workflow selects Node 24 and installs
npm@^11.5.1, but the provided diff contains no new or updated automated test for that behavior.

Rule 565552: Require regression test for every bug fix
.github/workflows/npmpublish.yml[23-33]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The publish workflow bug fix changes the Node and npm versions but adds no automated regression coverage for the compatibility failure described in the PR.
## Fix Focus Areas
- .github/workflows/npmpublish.yml[23-33]
## Recommended Fix
Add or update an automated workflow validation test that exercises the publish setup with Node 24 and verifies the configured npm range satisfies the trusted-publishing minimum without resolving to an incompatible npm major. Name the test after the Node/npm compatibility regression and ensure it would fail against the previous Node 25 plus `npm@latest` configuration.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can add REVIEW.md to your repo root and Qodo follows it on every PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[qodo-free-for-open-source-projects]

1. Publishing has no regression test 📘 Rule violation ▣ Testability

The workflow changes the publish runtime and npm version range without adding or updating an
automated test for the previously failing publish path. A future Node or npm compatibility change
can therefore reintroduce the EBADENGINE failure without a test detecting it before publishing is
blocked.

Agent Prompt

## Issue description
The publish workflow bug fix changes the Node and npm versions but adds no automated regression coverage for the compatibility failure described in the PR.

## Fix Focus Areas
- .github/workflows/npmpublish.yml[23-33]

## Recommended Fix
Add or update an automated workflow validation test that exercises the publish setup with Node 24 and verifies the configured npm range satisfies the trusted-publishing minimum without resolving to an incompatible npm major. Name the test after the Node/npm compatibility regression and ensure it would fail against the previous Node 25 plus `npm@latest` configuration.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Fix npm publishing with Node 24 and pinned npm 11

🐞 Bug fix ⚙️ Configuration changes 🕐 Less than 5 minutes

AI Description

• Runs package publishing on the supported Node 24 LTS line.
• Pins npm to compatible 11.x releases required for OIDC trusted publishing.
• Prevents future npm major releases from breaking the publishing workflow.

Diagram

graph TD
  A["Publish Job"] -->|configures| B["Node 24"] -->|installs| C["npm 11 Range"] -->|enables| D["OIDC Publish"]

Loading

High-Level Assessment

The PR's approach is optimal: Node 24 provides a supported LTS runtime, while the ^11.5.1 range meets OIDC requirements, accepts compatible npm 11 fixes, and prevents an incompatible future major upgrade. Using @latest recreates the failure risk, while an exact version would unnecessarily exclude compatible patches.

Files changed (1) +9 / -5

Bug fix (1) +9 / -5

npmpublish.ymlUse Node 24 and constrain npm to compatible 11.x releases +9/-5

Use Node 24 and constrain npm to compatible 11.x releases

• Changes the publishing runtime from unsupported Node 25 to Node 24 LTS. Replaces npm@latest with npm@^11.5.1 so trusted publishing remains available without automatically adopting incompatible npm majors, and documents the compatibility rationale.

.github/workflows/npmpublish.yml