Set node version to 24

[ingeniumed]

Summary

• Use Node.js 24 for local development and E2E CI.
• Refresh package-lock.json with Node.js 24 and npm 11.
• Remove stale optional dependency records without upgrading package versions.

Testing

• npm install should be sufficient

[pkevan]

Good — this completes the migration rather than starting one. e2e-tests.yml was the last workflow still on 22; release, integration, unit, static-checks and create-release-pr are all on 24 already, so this brings the outlier in line and the new .nvmrc matches.

One thing worth a look before merge: the lockfile loses six libc annotations, all on @rolldown/binding-linux-{arm64,ppc64,s390x,x64}-{gnu,musl} — exactly the packages where that field disambiguates a glibc build from a musl one. It lets npm skip the incompatible variant rather than attempting the wrong binary.

That field is emitted by npm 11, which is what Node 24 ships and what this same workflow pins one step later (npm install -g npm@11). So the lockfile appears to have been regenerated with an older npm, which is the opposite of the direction this PR is moving. Harmless on the glibc GitHub runners, but it means the committed lockfile no longer matches what CI's own npm would produce, and a future install could churn those lines back. Regenerating with npm 11 should restore them.

Also note the branch is four commits behind trunk, so the version diff in package-lock.json is just lag rather than a change — a rebase will make the diff read cleanly.

[acicovic]

Updating to 24 used to fail — see #67, where the Install Playwright browser step hung. That's why #36 pinned 22, and #69 pinned npm instead. It's been green across four runs here, so that part is good with me.

My question is the package-lock.json removal — what does it achieve? Node 24 bundles npm 11.17, and that npm writes those libc fields, so a genuine refresh on Node 24 returns trunk's lockfile unchanged. Removing them is what npm 10.9.2 produces, which is what Node 22 bundles. No functional impact either way (dev-only optional Linux bindings), but it's unrelated to the Node bump and strictly loses metadata, so I'd revert package-lock.json to trunk's version.