A range resolved over the lockfile picks a version only the lockfile holds instead of deduping #17084

What happens

The registry has @pnpm.e2e/foo 100.0.0 and 100.1.0. Two other fixture packages are involved:

• @pnpm.e2e/has-foo-as-dep-and-subdep depends on @pnpm.e2e/foo@100.0.0 and @pnpm.e2e/requires-any-foo, which depends on @pnpm.e2e/foo@*.
• @pnpm.e2e/has-foo100-peer declares @pnpm.e2e/foo@100 as a peer.

app depends on @pnpm.e2e/has-foo100-peer@1.0.0 and "provider": "npm:@pnpm.e2e/has-foo-as-dep-and-subdep@1.0.0".

A fresh install resolves requires-any-foo's * to 100.0.0, the version already in the graph. The peer binds to 100.0.0, and the lockfile holds one copy of foo.

Two sequences end with the same manifests but a different lockfile:

1. Provider moves and moves back. Change provider to npm:@pnpm.e2e/has-foo-100.1.0-dep-1@1.0.0, which depends on foo@100.1.0, and install. Then change it back and install again. requires-any-foo's * now resolves to 100.1.0, which only the previous lockfile held. The peer binds to 100.1.0 too, and the lockfile holds both copies. This happens with and without autoInstallPeers and dedupePeerDependents.
2. Dependencies added one at a time, with autoInstallPeers. Install app with has-foo100-peer alone, which auto-installs foo@100.1.0. Then add provider. requires-any-foo's * resolves to the locked 100.1.0, and the peer stays on it.

In both sequences, a version that only the lockfile weights outranks the version the graph already resolved. The new * dependency then keeps that version reachable, so the peer stays on it as well.

Expected

Installing over the lockfile writes the lockfile a fresh install writes: one copy of foo@100.0.0, with the peer bound to it.

Versions

Reproduced on main with pnpm v11 and v12. v12 with autoDedupe: true converges.

Found by the provider-move check of the peer convergence harness for pnpm/tasks#143.

Written by an agent (Claude Code, claude-opus-5-5).