fix: Prevent pnpm overrides from corrupting resolved peer-dep variants

[frankeld]

Description

When a pnpm lockfile has overrides (e.g. foo: ~1.0.0), turbo prune can produce a broken lockfile that's missing snapshot entries for packages with multiple peer-dependency variants. This happens because apply_overrides corrupts already-resolved version strings like 1.0.0(peer-a@1.0.0)(peer-b@2.0.0) by replacing them with the semver range from the override.

This fix makes resolve_specifier prefer the original specifier when it already matches a snapshot, so overrides only kick in when the specifier doesn't already resolve to a known package.

These issues are reoccurring for many different users. See ongoing bug reports on this closed issue: #3382 (comment)

Here's a repository with a "real" minimal reproduction: https://github.com/frankeld/turbo-prune-repro

Testing Instructions

New unit tests in crates/turborepo-lockfiles/src/pnpm/data.rs:

cargo test -p turborepo-lockfiles test_override_does_not_break_transitive_peer_variant

This test sets up a v9 lockfile with an override (foo: ~1.0.0) and two peer-dep variants of foo, then verifies that:

• resolve_package still resolves the transitive variant (foo@1.0.0(peer-a@1.0.0)(peer-b@2.0.0))
• The transitive closure includes both variants and middleware

[vercel]

@frankeld is attempting to deploy a commit to the Vercel Team on Vercel.

A member of the Team first needs to authorize it.