turbo

68eb2233 - fix: Filter orphaned Yarn packageExtensions entries during lockfile pruning (#12084)

fix: Filter orphaned Yarn packageExtensions entries during lockfile pruning (#12084) ## Summary - Fixes `turbo prune` leaving orphaned lockfile entries from Yarn's built-in `packageExtensions` (plugin-compat), which caused `yarn install --immutable` to fail on the pruned output - Adds a lockfile test fixture reproducing the issue Closes #11744 ## Background Yarn's [plugin-compat](https://github.com/yarnpkg/berry/blob/master/packages/yarnpkg-extensions/sources/index.ts) transparently injects dependencies into certain packages (e.g., `@types/keyv` and `@types/responselike` into `got@<11`). These injected deps appear as resolution entries in `yarn.lock` but are NOT recorded in the package's explicit dependency list. Previously, `subgraph()` in the Berry lockfile pruner unconditionally included all these "extension" resolution entries. When pruning to a workspace that doesn't transitively depend on the package that triggered the extensions, the entries were left orphaned — Yarn would try to remove them during `yarn install --immutable`, causing a failure. ## Fix Instead of unconditionally including all extensions, we now collect all dependency names from the pruned transitive closure and only include an extension if a related package name appears as a dependency. For `@types/X` extensions, we check if `X` is a dependency name in the closure. When an extension is included, its own transitive dependencies are also added. ## Testing Verified with `check-lockfiles --pm yarn-berry` — all 52 berry fixture tests pass (including the 2 new ones for this issue).