Three tests in `pacquet/crates/cli/tests/pnpm_compatibility.rs` run
pnpm and pacquet against the same workspace+lockfile with
`enableGlobalVirtualStore: true` and diff the resulting GVS slot
trees:

* `same_global_virtual_store_layout_pure_js` — one package + one
  transitive dep.
* `same_global_virtual_store_layout_with_approved_postinstall` —
  exercises the engine-included hash branch via `allowBuilds`.
* `same_global_virtual_store_layout_diamond` — exercises
  `calc_dep_graph_hash` memoization through a shared transitive.

All three fail today. The diffs surface three classes of divergence
the GVS port still has to close:

* Store prefix — pnpm writes `<store>/v11/links/...`, pacquet writes
  `<store>/links/...` (one level shallower than `getStorePath`).
* Bin shims — pacquet writes `.cmd` / `.ps1` cross-platform shims
  that pnpm doesn't, and pnpm writes a self-bin entry inside the
  package's own slot that pacquet doesn't.
* Engine-included hash — pacquet and pnpm disagree on the digest for
  an approved-build package
  (`pre-and-postinstall-scripts-example@1.0.0`: pacquet
  `6ce6f09e...`, pnpm `e0d69b24...`). Non-builder children still
  hash identically, so the gap is localised to the engine payload.

Pnpm runs first in each test so the lockfile exists before pacquet
starts — pacquet's GVS write path is gated on
`frozen_lockfile && enable_global_virtual_store`, so a fresh install
with no lockfile would silently fall through to the project-local
layout and the test would pass for the wrong reason.

Two divergences in the slot-local `node_modules/.bin/` writer
surfaced by `same_global_virtual_store_layout_*` and now reconciled
with pnpm:

* **`.cmd` / `.ps1` siblings only on Windows.** Pacquet was emitting
  all three shim flavors per bin (canonical no-extension shim,
  `.cmd`, `.ps1`) regardless of host platform, on the theory that a
  Linux-installed `node_modules` should stay usable when carried to
  Windows via network share or git clone. Pnpm does not match that
  contract — `@zkochan/cmd-shim` defaults
  [`createCmdFile: isWindows`](https://github.com/pnpm/cmd-shim/blob/0d79ca9534/src/index.ts#L32),
  and pnpm's `bins.linker` overrides `createPwshFile` with
  [`POWER_SHELL_IS_SUPPORTED = IS_WINDOWS`](https://github.com/pnpm/pnpm/blob/29a42efc3b/bins/linker/src/index.ts#L28),
  so neither sibling lands on Unix. Pacquet now gates the same way,
  removing the extra `.cmd`/`.ps1` files in every Unix slot. The
  upgrade-recovery test that exercised the "older pacquet wrote
  canonical only" repair path is now `#[cfg(windows)]` — on Unix
  there are no `.cmd`/`.ps1` siblings to recover.

* **Self-bin in the slot's own `.bin/`.** Pnpm's
  [`linkBinsOfDependencies`](https://github.com/pnpm/pnpm/blob/29a42efc3b/building/during-install/src/index.ts#L272-L298)
  appends `depNode` to the bin-source list unconditionally (line
  287), so a package like `hello-world-js-bin` (no deps, one bin)
  writes `<slot>/node_modules/<pkg>/node_modules/.bin/<pkg>` as a
  self-shim. Pacquet's `run_lockfile_driven` excluded the slot's own
  package based on a stale assumption ("which pnpm doesn't"); the
  parity tests surfaced the gap. Now the lockfile-driven path adds
  the slot's package as a bin source when its `has_bin` lockfile
  row is set, mirroring pnpm. The `run_with_readdir` fallback used
  by the non-lockfile install path still excludes self via
  `link_bins_excluding` — that one runs only for the legacy flat
  layout where GVS parity isn't a constraint, so the divergence is
  out of scope here.

The two pacquet GVS parity tests that didn't depend on engine-hash
parity (`..._pure_js` and `..._diamond`) now pass. The
`..._with_approved_postinstall` test still fails until a `@pnpm/exe`
build with the engine-name fix from 6fd9184 reaches the host.

Also updates three project-registry assertions in
`install::tests` that hard-coded `<store_dir>/projects/` to the
post-64a4a1d40b `<store_dir>/v11/projects/` location.

Extends the engine-name fix in 8f05529 to also honour
`engines.runtime` / `devEngines.runtime` Node pins. Before this
change `engineName()` resolved the Node major via
`getSystemNodeVersion()` (which is correct for non-SEA pnpm with no
runtime pin and for SEA pnpm with no runtime pin), but for a project
that pinned a Node version via `devEngines.runtime` the GVS hash
and the side-effects-cache key still tracked whichever Node the
runner happened to be on — not the pinned Node that scripts will
actually spawn under. Two installs of the same project on hosts
with different shell Nodes would therefore disagree on the slot
path even though every lifecycle script in either install would
run on the same downloaded Node.

Resolution order in `engineName(nodeVersion?)` is now:

1. Explicit override (the project's resolved `engines.runtime`
   version, threaded through by the install pipeline).
2. `getSystemNodeVersion()` — shell `node --version` for SEA pnpm,
   `process.version` otherwise.
3. `process.version` as a last-resort fallback.

`@pnpm/engine.runtime.system-node-version` gains a
`findRuntimeNodeVersion(snapshotKeys)` helper that scans an iterable
of lockfile snapshot keys for `node@runtime:<version>` and returns
the bare version string (peer suffixes stripped). Every install-side
caller of `calcDepState` / `calcGraphNodeHash` /
`iterateHashedGraphNodes` (`deps.graph-builder`,
`installing.deps-resolver`, `installing.deps-restorer`,
`installing.deps-installer`, `building.during-install`,
`building.after-install`) now computes
`findRuntimeNodeVersion(Object.keys(graph))` once per invocation and
forwards it through the new `nodeVersion?` option/parameter.

The hasher's option/parameter is optional with the same default the
no-arg `engineName()` produces — existing call sites and tests keep
working unchanged.

Pacquet mirrors this with a `find_runtime_node_major` helper in
`install_frozen_lockfile.rs`: before falling through to the host
`node --version` probe, it scans the lockfile's `snapshots:` map
for a `node@runtime:<version>` entry and uses that major outright.
The probe is skipped entirely when the pin is present.

Three new TS unit tests in
`engine.runtime.system-node-version`'s test file cover the override
branch and `findRuntimeNodeVersion`'s extraction rule (with and
without peer suffix). The pacquet runtime-fixture integration tests
(`install/tests.rs` around line 2537) continue to pass with the
helper engaged.

* **`findRuntimeNodeVersion` was scanning the wrong keys** in the
  hoisted-restorer paths. `DependenciesGraph` in
  `installing/deps-restorer/` is keyed by *install directory*, not
  depPath, so `Object.keys(opts.depGraph)` / `Object.keys(graph)`
  never saw `node@runtime:<version>` entries — the runtime pin was
  silently ignored on every headless install. Switched both
  `linkAllPkgs` (in `installing/deps-restorer/src/index.ts`) and
  `linkHoistedModules` (in `linkHoistedModules.ts`) to pull the
  depPath off each node, and lifted `linkAllPkgsInOrder`'s
  computation out of the recursion so the scan runs once per
  invocation instead of at every directory level.

* **Newline safety in the test-fixture YAML helper.** The
  `enable_gvs_in_workspace_yaml` helper concatenated
  `enableGlobalVirtualStore: true\n…` directly onto the existing
  file contents. If the helper that produced the file ever drops
  the trailing newline, the result would merge the last key with
  ours and yield invalid YAML. Forces a `\n` boundary before the
  append.

* **`cargo fmt` drift.** `cargo fmt --all -- --check` flagged
  trivial line-break differences in three files; re-formatted.

* **`cspell` complained about two words.** Rewrote
  `materialise` (British) → `materialize` in
  `engine.runtime.system-node-version`'s docstring and
  `unsuffixed` → `the form without a peer suffix` in the test
  comment.

* **`dylint` flagged an unused import.** `remove_file` is only
  consumed by the Windows-only upgrade-recovery test added in
  b13ec21, so its `use` line is now `#[cfg(windows)]`-gated.

The stale `.cmd` / `.ps1` cleanup CodeRabbit flagged on
`pacquet/crates/cmd-shim/src/link_bins.rs:468` is a real but
narrower upgrade-path concern (pacquet v1 → v2 reinstall leaves
legacy Windows shims in the slot indefinitely). It's tracked
separately rather than handled here; the new install / fresh slot
path already converges, and `pnpm store prune` + reinstall clears
any leftovers.

`@pnpm/engine.runtime.system-node-version` slotted in alphabetically
behind `@pnpm/deps.path` in the three files where the dep was
plumbed through in b59c5df, putting the import out of order
relative to `@pnpm/deps.graph-sequencer` / `@pnpm/deps.graph-hasher`
(which sort before it lexicographically). `eslint --fix` shuffles
the import block back into shape — no semantic change, just
reordering.

Closes the last CI lint failure on PR #11689.

…gh dlx.e2e.ts mock

`dlx.e2e.ts` uses `jest.unstable_mockModule` to wrap
`@pnpm/engine.runtime.system-node-version`, re-exporting only
`getSystemNodeVersion`. After 6fd9184 / b59c5df the same
module also exports `engineName` and `findRuntimeNodeVersion`, and
`@pnpm/deps.graph-hasher` started importing `engineName`
dynamically when the test's `await import('@pnpm/installing.commands')`
chain pulled it in. ESM saw the named import miss against the
mocked module and threw `SyntaxError: The requested module does
not provide an export named 'engineName'` at test-suite startup —
broke `ubuntu-latest / Node.js 24 / Test` on PR #11689.

The mock now forwards every public symbol the real module surfaces:

* `getSystemNodeVersion` keeps the `jest.fn` wrapper so existing
  call-spy assertions still work.
* `engineName` and `findRuntimeNodeVersion` delegate straight back
  to the originals — no spy needed; they're transitive consumers
  rather than the subject of any assertion in this file.

… args into options bag

`hashDependencyPaths` had grown to four positional args after
b59c5df added `nodeVersion`, putting it past the
two-or-three-arg threshold from `CONTRIBUTING.md` (and CodeRabbit
flagged the call site at `iteratePkgsForVirtualStore.ts:42`). The
helper is private to this file with one caller, so collapsing to
`hashDependencyPaths(lockfile, { allowBuild, supportedArchitectures,
nodeVersion })` is a contained change.

`iterateHashedGraphNodes` itself still uses positional args
(graph, iterator, allowBuild?, supportedArchitectures?,
nodeVersion?) — that's a public API of `@pnpm/deps.graph-hasher`
with external callers in `deps.graph-builder`,
`installing.deps-resolver`, `engine.pm.commands` and several
tests, so reshaping it would balloon scope beyond what's in this
PR.