`tryFrozenInstall` runs for both the explicit `--frozen-lockfile` case
and the optimistic frozen-like path (when `preferFrozenLockfile` is set
and all projects are already up-to-date). Pacquet only implements the
frozen-install path; without `--frozen-lockfile` it takes a code path
that doesn't emit the full event sequence (no `pnpm:stats`, no
`pnpm:summary`), so the reporter renders progress but no summary.

Always pass `--frozen-lockfile` when delegating: we only reach this
branch from `tryFrozenInstall`, which has already established the
lockfile is good enough to install from without resolution.

The fake pacquet binary is a JS file with a Node shebang. Direct
`spawn` of a file relies on shebang execution, which Windows
doesn't honor, so the tests fail there with `spawn UNKNOWN`. The
production code path is unaffected — pacquet on Windows ships a
native `.exe`. A Windows-flavored fixture would need a `.cmd`
shim or a real Win32 executable; skip until that's worth building.

…cquet

Drops the unit suite under installing/commands/test/runPacquet.ts —
its fake binary was a JS file with a Node shebang, which doesn't work
on Windows and forced a platform skip. Replace it with an e2e at
pnpm/test/install/pacquet.ts that installs the real pacquet from the
public npm registry, runs a full `pnpm install --frozen-lockfile`
against a real package, and asserts the delegation log fires. The
real pacquet ships a native `.exe` on Windows so the e2e exercises
the same code path on every platform.

Follows the precedent in pnpm/test/install/minimumReleaseAge.ts and
pnpm/test/dlx.ts of pinning a specific test to the public registry
when the mocked registry can't carry the fixture.

Drop the platform map — the wrapper's layout is just
\`<platform>-<arch>/pacquet[.exe]\`, so a one-liner does it. An
unsupported host falls through to the spawn \`ENOENT\`, which carries
the missing path in its own error message.

The frozen-install path is no longer special-cased. Anywhere pnpm
would have called \`headlessInstall\` to materialize an
already-resolved lockfile, pacquet takes over instead when configured:

- frozen install (\`tryFrozenInstall\`) — unchanged
- workspace partial install (\`installInContext\` — when the mutated
  project set is a subset of the workspace; pnpm runs a
  \`lockfileOnly\` resolve pass first)
- hoisted \`nodeLinker\` install (\`installInContext\` — same
  resolve-then-materialize pattern)
- agent-server install (server-side resolution via
  \`@pnpm/agent.client\`)

Pnpm still owns dependency resolution everywhere. Pacquet only fetches
and imports from the freshly-written lockfile, which is on disk in each
case before pacquet spawns (\`writeWantedLockfileAndRecordVerified\` in
the resolve-then-materialize paths, the existing \`pnpm-lock.yaml\` in
the frozen path). A new \`materializeOrDelegate\` helper keeps the
per-callsite delegation choice in one place.

When pacquet is configured and the install would otherwise take the
default isolated-nodeLinker fall-through in \`installInContext\`,
split it: ask the JS engine for a \`lockfileOnly\` resolve pass (which
writes \`pnpm-lock.yaml\`), then hand off the fetch / import / link /
build phases to pacquet against the freshly-written lockfile. Pnpm
keeps owning resolution — pacquet's resolver isn't ready yet — but the
rest of the materialization runs in Rust.

The frozen path already delegated inside \`tryFrozenInstall\`, and the
workspace-partial and hoisted-linker paths already followed the same
resolve-then-materialize shape (their \`headlessInstall\` callsites
went through \`materializeOrDelegate\` in the prior commit). This
closes the loop for the most common install shape: \`pnpm install\` on
a single project (or full workspace) with the default isolated linker.

\`installDeps\` constructed \`runPacquet\` only inside the
single-project \`installOpts\` block. The two workspace-recursive
call sites (the workspace-root install and the
\`--link-workspace-packages\` follow-up) reached
\`recursiveInstallThenUpdateWorkspaceState\` without it, so any
\`pnpm install\` run from a workspace root never reached the
delegation branch even when pacquet was declared in
\`configDependencies\`.

Hoist the construction above the workspace fork, add a \`runPacquet\`
slot to \`RecursiveOptions\`, and pass it down both recursive call
sites. The single-project \`installOpts\` block reuses the same
callback.

…uire

Pacquet's npm package ships an empty \`node_modules\` after the
configDependencies install — the platform binary sub-package
(\`@pacquet/<platform>-<arch>\`) lands as a *sibling* of pacquet in
the global virtual store, not inside pacquet's own \`node_modules\`.
The hand-built path
\`node_modules/.pnpm-config/pacquet/node_modules/@pacquet/...\` was
wrong; spawn failed with \`ENOENT\`.

Switch to \`createRequire(pacquet/package.json).resolve(...)\` — same
algorithm the upstream wrapper at \`pacquet/npm/pacquet/bin/pacquet\`
uses. Node walks the symlinked package's neighborhood and finds the
binary regardless of how the package was hoisted.

\`.pnpm-config/pacquet\` is a symlink into the global virtual store,
and Node's \`createRequire\` builds its NODE_MODULES_PATHS from the
*literal* ancestors of the path it's given — it doesn't follow the
symlink up to where the \`@pacquet/<platform>-<arch>\` sibling
actually lives. Realpath the package.json before passing it in so
the resolver walks the store dir's neighborhood.

Verified against \`/private/tmp/pnpm.PYO7vjG6Ff\`: \`createRequire\`
on the symlinked path threw MODULE_NOT_FOUND, on the realpath
returned the binary at \`...store/.../node_modules/@pacquet/darwin-arm64/pacquet\`.

…warding to pacquet

Dev wrappers like \`pnpm/dev/pd.js\` inject global flags (e.g.
\`--pm-on-fail=ignore\`) ahead of the user's command, so the command
name alias (\`install\` / \`i\`) doesn't always sit at index 0. The
old \`argv.slice(1)\` dropped the injected flag and forwarded the
command name to pacquet, where it appeared as an unexpected duplicate
positional and clap rejected with \`unexpected argument 'install'
found\`.

Drop the first arg that doesn't start with \`-\` instead. That's
always the pnpm subcommand by construction.

\`_installInContext\` fires \`summaryLogger.debug({prefix})\` after
resolution. The default reporter's \`reportSummary\` does
\`log\$.summary.pipe(take(1))\` and combines it with whatever
\`pkgsDiff\` it has at that moment — pkgsDiff is built from
\`pnpm:root\` add/remove events, which pacquet emits during linking,
*after* pnpm's lockfileOnly resolve pass finishes.

Result: when pacquet was taking over the materialization, pnpm's
summary fired before any root events had arrived, the
\`combineLatest\` locked in an empty diff, and the install rendered
no \`+ pkg version\` lines. Pacquet's own \`pnpm:summary\` came too
late — \`take(1)\` had already settled on pnpm's.

Skip the summary emit when \`opts.runPacquet\` is set. Pacquet emits
its own summary after the install completes, by which point its
root events have populated the diff. Same shape as the
\`importing_done\` suppression in the previous commit.

…t will materialize

The reporter accumulates \`pnpm:progress status:resolved\` events per
requester; pnpm's resolver emits one per unique package on first
resolution, and pacquet emits one per package when it walks the
lockfile. Both share the same requester (\`lockfileDir\`), so the
reporter's resolved counter ends up at 2× the lockfile size.

Thread a \`suppressResolveProgress\` flag through
\`ResolveDependenciesOptions\` → \`ResolutionContext\` and gate the
\`progressLogger.debug\` call inside \`resolveDependency\`. Set the
flag from \`installInContext\` when \`opts.runPacquet\` is set.

…n pacquet will materialize"

This reverts commit 844a139.

…ing pnpm's

Reverses the suppression direction. pnpm's resolver is the side that
actually does the resolution; pacquet's per-package
\`pnpm:progress status:resolved\` events are emitted purely for
wire-format parity as it walks the already-resolved lockfile. The
authoritative resolved counter should reflect what was actually
resolved, so keep pnpm's emit and filter pacquet's on the way back
through the runPacquet stderr reader. The other status values
(\`fetched\`, \`found_in_store\`, \`imported\`) are pacquet-only and
still pass through.

…lved first

The previous version filtered \`pnpm:progress status:resolved\`
unconditionally — but on the frozen-install path \`tryFrozenInstall\`
hands off to pacquet without running a resolve pass at all, so
pacquet's events are the only source and the reporter would show
zero resolved.

Make the filter a per-invocation flag on the runPacquet callback
(\`filterResolvedProgress\`). Set \`true\` from the
resolve-then-materialize callsites (workspace-partial, hoisted-linker,
agent-install, default-isolated) — they each ran a lockfileOnly
resolve pass first, so pnpm already emitted the resolved events the
reporter counts. Leave it unset on the frozen path.

…acquet\`

The Rust install engine is now published under two names: the
original unscoped \`pacquet\` (preserved for back-compat) and the
official scoped \`@pnpm/pacquet\` mirror. Both packages ship the
same JS shim and share the same \`@pacquet/<plat>-<arch>\` binary
sub-packages — the per-platform artifacts stay under the
\`@pacquet/\` scope, only the wrapper has a scoped alias.

\`pacquet/npm/pacquet/scripts/generate-packages.mjs\` generates the
mirror in \`pacquet/npm/pnpm-pacquet/\` after \`writeManifest\` has
patched the version and optionalDependencies, then copies the shim
across and swaps only the package name (and the \`repository.directory\`
pointer). The release workflow publishes the new directory alongside
the existing ones.

The pnpm CLI delegation accepts either name in
\`configDependencies\` — it picks whichever is declared and looks
under \`node_modules/.pnpm-config/<that name>/\` for the wrapper.

…ropped ones

\`pnpm add\` and \`pnpm update\` carry flags (\`--save-dev\`,
\`--save-peer\`, \`--filter\`, …) that pacquet's \`install\` subcommand
doesn't recognize, and clap rejects unknown flags — so forwarding
broke those commands the moment pacquet was configured.

Switch to fixed args: pacquet always runs as
\`install --frozen-lockfile --reporter=ndjson\`. Settings users care
about live in \`pnpm-workspace.yaml\` / \`.npmrc\`, which pacquet
reads on its own.

Emit a warning when the user's argv carries any flag-looking token
(excluding the ones we always emit ourselves and \`--config.*\` which
configures pnpm's runtime). The warning lists the dropped flags
explicitly and points to the workspace yaml as the alternative — so
\`pnpm install --prod\` doesn't silently install dev deps via pacquet.

\`logger.info({ message: 'Delegating install to pacquet ...' })\`
rendered as a plain info line, easy to miss in a busy install.
Replace with a chalk-styled two-line banner — magentaBright header
plus a gray subhead — so users can see at a glance that the Rust
engine is taking over the install. Same dependency the default
reporter uses for its summary section, so colorization respects
the user's TTY settings consistently.

Update the e2e assertions to match the new wording.

…dules.yaml matches

Two distinct failures in the e2e suite:

1. \`install --frozen-lockfile\` / bare \`install\`: asserted against
   stderr, but pnpm's append-only reporter (the one selected in the
   test environment because there's no TTY) writes to stdout by
   default — \`useStderr\` isn't set in the test env. The captured
   stderr was empty, so the contain-check failed. Switch the
   destructure + assertion to stdout.

2. \`pnpm add\` / \`pnpm update\`: \`ERR_PNPM_PUBLIC_HOIST_PATTERN_DIFF\`
   on the second invocation. The first install delegates to pacquet,
   which writes a \`.modules.yaml\` whose \`publicHoistPattern\`
   differs from what pnpm computes when it reads the file back on the
   follow-up command. That's a pacquet-side parity gap — the
   frozen-install and bare-install tests escape it by wiping
   \`node_modules\` between invocations; \`add\` / \`update\` can't,
   they need the prior install's state. Mark both \`test.skip\` with a
   pointer comment until pacquet's \`.modules.yaml\` matches pnpm's
   shape.