[BUG] `npm install` does not repair invalid or missing lockfile deps behind a workspace, so `strict-peer-deps` passes

Is there an existing issue for this?

• I have searched the existing issues

This issue exists in the latest npm version

• I am using the latest npm

This is not just a request to bump a dependency for a CVE

• This is not solely a request to bump a dependency for a CVE

Current Behavior

When a lockfile already exists, npm install never checks the dependency edges of packages reached through a workspace. A lockfile written with legacy-peer-deps keeps its invalid peers, and a strict-peer-deps install exits 0 while npm ls reports invalid. The same tree declared at the root fails with ERESOLVE, and the default mode is affected too (no warning, missing transitive deps also stay missing).

Expected Behavior

Workspace subtrees are validated like the root: the invalid peer is re-resolved or fails with ERESOLVE, as it does without workspaces or without a lockfile.

Steps To Reproduce

mkdir x && cd x && mkdir -p packages/a
echo '{"name":"r","workspaces":["packages/*"],"dependencies":{"redux":"5.0.1"}}' > package.json
echo '{"name":"a","dependencies":{"redux-thunk":"2.4.2"}}' > packages/a/package.json
npm install --legacy-peer-deps
npm install --strict-peer-deps   # expected ERESOLVE, actual exit 0
npm ls --all                     # redux@5.0.1 deduped invalid: "^4" from node_modules/redux-thunk
# Control: put redux-thunk in the root dependencies instead, and the second install fails with ERESOLVE.

Environment

• npm: 12.0.2 (latest source), hoisted and linked
• Node.js: v24.18.0
• OS Name: macOS Darwin 25.6.0

Reproduce the behavior using the root package.json and packages/a/package.json commands, starting with npm install --legacy-peer-deps followed by npm install --strict-peer-deps and npm ls --all. Trace how npm validates workspace dependency edges and compare the workspace case with the root-dependency control; done means invalid peers are re-resolved or the install fails with ERESOLVE.