Nixpacks' npm ci step was failing with "Missing: X@... from lock
file" for unstorage's optional peer dependency on lru-cache (never
actually installed, since this app uses none of unstorage's optional
cloud-storage drivers). This is a known npm bug (npm/cli#9083, fixed
in npm 11.11.1): npm ci built its lockfile-validation "virtual tree"
and install "ideal tree" with a shared Arborist instance, incorrectly
flagging legitimately-absent optional deps as missing. Nixpacks'
nodejs_22 nix package almost certainly bundles an older, unfixed npm.

package.json/package-lock.json are confirmed in sync (fresh reinstall
produces zero diff), so this isn't a real lockfile problem — routing
Nixpacks' install phase through npm install instead sidesteps the
buggy npm ci codepath entirely, regardless of npm patch version.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

)

`npm ci` failed on a clean checkout with EUSAGE, naming a version that
appears nowhere in package-lock.json:

    npm error Missing: esbuild@0.28.2 from lock file
    ... (+26 @esbuild/* platform packages, all 0.28.2)

while `npm install --package-lock-only --dry-run` reported "up to date".

The lockfile is not at fault and is unchanged here. `vitest`'s nested
`vite@8.2.2` declares esbuild as an *optional* peerDependency
(`^0.27.0 || ^0.28.0`, `peerDependenciesMeta.esbuild.optional = true`),
and nothing in the lock satisfies that edge at that location — which is
correct, because an unsatisfied optional peer should be skipped. Older
npm instead resolves it against the registry (arborist's `loadPeerSet`),
picks up whatever is current, then rejects the lock as out of sync. That
is also the install-vs-ci contradiction: the two commands build the tree
by different paths and disagree about optional peers.

Fixed upstream by npm/cli#8981 (npm 11.10.1) and npm/cli#9083
(npm 11.11.1). Node 24.15.0 is the first 24.x bundling npm >= 11.11.1.

CI was never affected: `.nvmrc` is bare `24`, so setup-node floats to
v24.19.0 / npm 11.17.0. The failure only reached environments sitting on
an old-but-in-range Node 24, which `engines.node: ">=24"` permitted.
Regenerating the lockfile under npm 11.17.0 reproduces it byte for byte;
regenerating under an affected npm instead commits esbuild 0.28.2 and 26
platform packages that CI does not install.

`.nvmrc` deliberately stays bare `24` — the repo pins by major, and
scripts/check-node-version.sh compares majors only, so it still passes.

Also corrects two references the new floor invalidated: the Dockerfile
comment that quoted "node >=24" (now states the floor without repeating
a value that can drift) and the docs/ops.md local-dev requirement.