[N/A] Read the Node version from .nvmrc

[bd-viget]

Summary

CI pinned Node 22.12.0 while .ddev/config.yaml provisions 24.13.0. So CI built the theme on a toolchain no developer actually uses.

Worse: 22.12.0 ships npm 10.9, and the theme's own package.json declares "engines": { "npm": ">=11.0.0" }. npm doesn't enforce engines without engine-strict, so CI has been quietly building below the theme's declared floor.

.nvmrc now holds 24.13.0 to match DDEV, and build.yaml and deploy.yaml both read it.

Why now

viget-blocks-toolkit's v1.1.9 release build failed at npm ci with 41 Missing ... from lock file errors - its ci.yaml had moved to Node 24 and its release.yaml hadn't, and npm 10 can't install an npm 11 lock. CI was green; the break only appeared on the tag push.

Same class of problem here, one step earlier: nothing has broken yet because CI's npm 10.9 can still read the committed lock. It stops being able to the moment someone runs npm install in DDEV (npm 11) and commits the result - which is the normal workflow.

The fix that matters isn't the version number, it's having one source so CI, DDEV and the release path can't disagree.

Same pass in the plugin repos: viget-blocks-toolkit#40, viget-post-type-taxonomy-sync#17, mega-menu-block#27.

Verified

npm ci in wp-content/themes/wp-starter on node:24.13.0-slim - exit 0, npm 11.6.2, no missing lock entries.

Note

No changelog entry here - CI only, no runtime change. If you'd rather it appear in 1.1.0, it's a one-liner to fold into #266's ## v1.1.0 section, and doing it there avoids the two PRs conflicting on CHANGELOG.md.

Issues

• N/A

Testing Instructions

1. CI green - the theme build is the real check.
2. ddev start still works, since .nvmrc matches what DDEV already provisions.