Decide supported Node contract before updating jsdom

[lamemustafa]

Problem

Dependabot PR #343 updates jsdom to a release whose supported Node range excludes the project’s advertised minimum Node version. Current CI uses a newer Node release, so it does not establish support at the documented floor.

Decision required

Choose one coherent path:

1. retain the existing Node support contract and select a compatible jsdom release; or
2. raise the supported Node floor across package metadata, README, CI, and contributor guidance.

Acceptance

• Run jsdom-backed tests at the selected minimum and current supported Node versions.
• Regenerate compatibility metadata and pass normal frontend checks and current-head CI.

Regression source

Discovered while reviewing Dependabot PR #343. It is intentionally held; no successor PR should be created until the support-contract decision is made.

[lamemustafa]

Decided and shipped in #386, now merged.

The decision: option 2 — raise the supported Node floor rather than hold jsdom back.

	before	after
package.json engines.node	>=22.12 <25	>=24.15.0 <25
.node-version	24.18.0	24.21.0
jsdom	^28.1.0 (held)	^30.0.1
README.md	"Node.js 22 or 24"	"Node.js 24 (>=24.15.0)"
docs/release-process.md	"supported 22 or 24 releases"	"supported 24.x releases (>=24.15.0)"

Verified against nodejs.org/dist/index.json rather than assumed: v24 "Krypton" is the Active LTS, latest 24.21.0 (2026-09-07); v22 "Jod" is the older line and v26 is Current, not LTS.

The floor is 24.15.0 rather than 24.21.0 deliberately — 24.15.0 is jsdom 30's own minimum within the 24 line, so the declared contract and the dependency's real requirement now agree without rejecting contributors on earlier 24.x builds.

CONTRIBUTING.md and AGENTS.md state no Node version, so nothing was needed there. All six node-version-file: .node-version references across the workflows read the file at runtime and picked up 24.21.0 with no edit.

Against this issue's acceptance criteria — partially met, stated precisely

Run jsdom-backed tests at the selected minimum and current supported Node versions.

• Current supported version — met. CI ran the full matrix at 24.21.0 on the merge commit and passed, including the 8 jsdom-backed vitest suites (113 tests). jsdom 28→30 is a two-major jump, so those suites were the actual risk.
• Selected minimum (24.15.0) — NOT met. It was never executed. The machine this was prepared on has only Node 24.18.0 installed and no version manager (nvm/fnm/volta/asdf/n), so the floor is derived from jsdom's declared engines, not from a test run.

Regenerate compatibility metadata and pass normal frontend checks and current-head CI.

Met. package.json and pnpm-lock.yaml pins resealed with a confirming zero-change pass; license:all passes; current-head CI green.

Closing because the decision this issue asked for has been made and shipped. The 24.15.0 floor remains asserted rather than exercised — if you want it proven, that needs a deliberate run under a version manager at 24.15.0, and is worth a separate issue rather than holding this one open.

Also worth recording for whoever revisits this: .node-version was already 24.18.0 while engines still said >=22.12, so the declared contract and actual practice had been disagreeing for some time. That gap, more than jsdom, was the real content of this issue.