…st (#10655)

* fix: respect peer dep range in hoistPeers when preferred versions exist

Previously, hoistPeers used semver.maxSatisfying(versions, '*') which
picked the highest preferred version from the lockfile regardless of the
peer dep range. This caused overrides that narrow a peer dep range to be
ignored when a stale version existed in the lockfile.

Now hoistPeers first tries semver.maxSatisfying(versions, range) to find
a preferred version that satisfies the actual peer dep range. If none
satisfies it and autoInstallPeers is enabled, it falls back to the range
itself so pnpm resolves a matching version from the registry.

* fix: only fall back to exact-version range for overrides, handle workspace: protocol

- When no preferred version satisfies the peer dep range, only use the
  range directly if it is an exact version (e.g. "4.3.0" from an override).
  For semver ranges (e.g. "1", "^2.0.0"), fall back to the old behavior
  of picking the highest preferred version for deduplication.
- Guard against workspace: protocol ranges that would cause
  semver.maxSatisfying to throw.
- Add unit tests for hoisting deduplication and workspace: ranges.

* fix: only apply range-constrained peer selection for exact versions

The previous approach used semver.maxSatisfying(versions, range) for all
peer dep ranges, which broke aliased-dependency deduplication — e.g. when
three aliases of @pnpm.e2e/peer-c existed at 1.0.0, 1.0.1, and 2.0.0,
range ^1.0.0 would pick 1.0.1 instead of 2.0.0.

Now the range-aware logic only activates when the range is an exact
version (semver.valid), which is the override case (e.g. "4.3.0").
Regular semver ranges fall back to picking the highest preferred version.

Revert the workaround that forced `pnpm self-update` to always install
the `pnpm` package for v11+. Since `@pnpm/exe` works again from
v11.0.0-alpha.7, `getCurrentPackageName()` now simply returns
`@pnpm/exe` when running as an executable, without platform-specific
package names.

…nd shims (#10673)

Fixed "input line too long" error on Windows when running lifecycle scripts with the
global virtual store enabled. The `NODE_PATH` in command shims no longer includes all
paths from `Module._nodeModulePaths()`. Instead, it includes only the package's
bundled dependencies directory (e.g., `.pnpm/pkg@version/node_modules/pkg/node_modules`),
the package's sibling dependencies directory (e.g., `.pnpm/pkg@version/node_modules`),
and the hoisted `node_modules` directory. These paths are needed so that tools like
`import-local` (used by jest, eslint, etc.) which resolve from CWD can find the correct
dependency versions.

…dows

On Windows, temporaryDirectory() may return 8.3 short paths (e.g.,
RUNNER~1) but getBinNodePaths resolves via fs.realpath, returning long
paths (e.g., runneradmin). Use realpathSync to normalize expected paths.

… Windows 8.3 paths

fs.realpathSync uses a JS-only implementation that only resolves symlinks,
not Windows 8.3 short names (e.g., RUNNER~1). Switch to fs.promises.realpath
which uses the native uv_fs_realpath (GetFinalPathNameByHandleW on Windows)
to properly resolve 8.3 short paths to their long form.