…tokio worker

The pick-and-fetch path was calling synchronous `load_meta` and
`load_meta_headers` directly from async tasks. Each call reads the
mirror file (`fs::read_to_string`, a blocking syscall) and parses
the multi-KB to multi-MB packument body (`serde_json::from_str`,
CPU-bound). Neither yields, so the tokio worker stayed pinned for
the duration of every disk hit.

The hot path runs them on every cache-warm pick:
- `fetch_full_metadata_cached` calls `load_meta_headers` to feed
  the conditional GET headers.
- A 304 response then calls `load_meta` to re-materialise the
  packument.
- `pick_package`'s offline / pickLowestVersion, version-spec, and
  publishedBy shortcuts also call `load_meta` directly.

With ~600 unique packuments per install all running through this
sequence concurrently behind `try_join_all`, the blocking time
serializes against the worker pool size and the async scheduler
can't make progress on unrelated resolves / HTTP fetches in the
gaps.

This change adds async siblings — `load_meta_async` and
`load_meta_headers_async` — that dispatch the sync body to
`tokio::task::spawn_blocking`. Callers in `pick_package` and
`fetch_full_metadata_cached` await the async wrappers. The sync
functions stay (tests and the writeback path still call them
directly).

Matches upstream pnpm's posture, which performs the equivalent
work via awaited `fs.readFile` + `JSON.parse` on libuv's worker
pool.

Test: all 194 tests in `pacquet-resolving-npm-resolver` continue
to pass (existing `load_meta` / `load_meta_headers` coverage in
the mirror tests and via the fetcher integration tests is the
behaviour-level proof — the wrappers delegate verbatim).

`run_with_mem_cache`'s Available branches were re-emitting
`found_in_store` on every duplicate caller for an already-known
URL, so the per-package counter in pnpm's default-reporter ticked
by the number of resolve occurrences instead of by 1 — `~120×` on
the alotta-files benchmark, surfacing as a logged
`reused: 164746` for `1362` packages. The stderr write storm also
showed up directly as resolve-walk wall-clock.

Upstream's
[`packageRequester`](https://github.com/pnpm/pnpm/blob/086c5e91e8/installing/package-requester/src/packageRequester.ts#L410-L436)
attaches the emit via `.then()` on the first writer's promise;
later `await`s of the same promise do not re-trigger the handler.
This change matches that — only the first writer's
`run_without_mem_cache` call emits.

Inverts the existing
`mem_cache_hit_emits_found_in_store_for_second_requester` test to
`mem_cache_hit_does_not_re_emit_for_second_requester` — it now
asserts the second caller emits neither `found_in_store` nor
`fetched`.

…lockfile install

Under global virtual store the install side is essentially just
symlinking, so the resolve-walk wall-clock dominates — and almost
all of it ends up serialized on the `Arc<Mutex<StoreIndex>>`.

`run_with_mem_cache` → `run_without_mem_cache` calls
`load_cached_cas_paths` per package, which under the hood
`spawn_blocking`s a SQL `SELECT` against the shared store-index
mutex. When `PrefetchingResolver` fires that path once per resolve
occurrence (~1k spawns on the alotta-files fixture), the mutex
contention dominates wall-clock. `create_virtual_store::run`
already avoids this for the frozen-lockfile path via
`prefetch_cas_paths` — one batched `SELECT … WHERE key IN (…)`
followed by rayon-parallel per-row verify. This change ports that
shape to the fresh-lockfile path:

- After `resolve_importer`, walk the graph, collect every
  `(integrity, pkg_id)` cache key via the new
  `collect_prefetch_cache_keys` helper (mirrors the equivalent
  loop in `create_virtual_store::run`), run `prefetch_cas_paths`,
  and thread the resulting `PrefetchedCasPaths` through
  `InstallCtx` → `InstallPackageFromRegistry::run` →
  `DownloadTarballToStore` via the existing
  `prefetched_cas_paths` field.
- Drop the `PrefetchingResolver` wrapper. With the batched
  prefetch in place, the resolver chain is the plain
  `DefaultResolver` again — same setup the frozen-lockfile path
  uses.

Side effects:

- The `Resolved` → `found_in_store` → `Imported` emit ordering is
  fixed by construction: all three now fire from
  `InstallPackageFromRegistry::run` in that order. Previously the
  `PrefetchingResolver` spawn fired `found_in_store` from the
  resolve phase, before `Resolved` from the install phase.
- `prefetching_resolver.rs` is deleted.

Tests: 298/298 pass in `pacquet-package-manager`. Clippy clean.

…le install

To help target the remaining wall-clock gap, emit
`pacquet::install::phase` `tracing::info!`s at every major
boundary in `InstallWithFreshLockfile::run`:

- `resolve_importer`: deps-resolver walk
- `prefetch_cas_paths`: warm-cache batched lookup
- `build_fresh_lockfile`: graph → lockfile shape (GVS only)
- `virtual_store_layout_new`: per-snapshot GVS hash computation
- `install_subtree`: the per-package install fan-out

Carries the relevant counters (graph size, cache-key count, prefetch
hits) so a single trace tells us which phase dominates.

Run with `TRACE=pacquet::install::phase=info` to see the timings
without other noise.

No behavior change — purely observational.

…ia Arc

`ResolveResult` propagates by clone — once into `ResolvedPackage`
in the deps-resolver's `TreeCtx`, again into each
`DependenciesGraphNode` in the peer-resolved graph, and a few more
times through the install dispatch. The `manifest` field is a
`serde_json::Value` tree (per-version body) and every clone walked
it node-by-node.

Wrap it in `Arc` so `ResolveResult::clone()` bumps a refcount
instead of deep-cloning the JSON tree:

- New `SharedDependencyManifest = Arc<DependencyManifest>` alias on
  `pacquet-resolving-resolver-base`.
- `ResolveResult::manifest` and `LatestInfo::latest_manifest`
  re-typed as `Option<SharedDependencyManifest>`.
- All construction sites in npm / git / tarball / local / runtime
  resolvers and `resolve_from_workspace` wrap their built `Value`
  in `Arc::new`.
- Read sites mostly worked unchanged via `Arc<Value>`'s `Deref`
  coercion. Two call sites that pass `Option<&Value>` to a helper
  (`manifest_unpacked_size`, `build_package_metadata`) switched to
  `.as_deref()`.

Mirrors JS object-reference semantics — pnpm's `pkgResponse.manifest`
is an object, not a deep copy, so propagating the response across
resolve / install pays no copy.

Tests: 295/295 in the resolver crates pass; 298/298 in
`pacquet-package-manager`. Clippy clean.

…tion

`build_resolve_result` was calling `serde_json::to_value(picked)`
on every resolve to populate `ResolveResult::manifest`. For 1362
resolved occurrences with ~600 unique `(name, version)` pairs the
same picked `PackageVersion` was walked and reserialised hundreds
of times.

New `PickedManifestCache = Arc<DashMap<String, Arc<Value>>>`
(`shared_picked_manifest_cache()`) threaded through `NpmResolver`
and `NamedRegistryResolver`. On the first pick of a
`(name, version)` pair the resolver serialises once and stores
the `Arc<Value>` under the `{name}@{version}` key; subsequent
picks `Arc::clone` instead of reserialising.

The cache is install-scoped — built once in
`InstallWithFreshLockfile::run` and shared between the two
resolvers so cross-registry picks of the same package version
also coalesce.

Tests: 295/295 in the resolver crates pass; 492/492 across
`pacquet-resolving-npm-resolver` + `pacquet-package-manager`.
Clippy clean.

… on TreeCtx

`TreeCtx`'s state (`packages`, `dependencies_tree`,
`all_peer_dep_names`, `policy_violations`, `applied_patches`) was
guarded by `tokio::sync::Mutex`. Every visit acquired 2-3 of them
behind `.lock().await`, paying the async-mutex per-acquire
overhead (registration, future polling, wake) on the resolve hot
path.

None of the critical sections hold the lock across an `.await` —
they're short `HashMap` / `HashSet` inserts and `Vec::push`es.
That's exactly the shape `std::sync::Mutex` is for. Switch the
fields, remove the `.await`s, and route every acquire through a
new `lock_recoverable` helper that mirrors the rest of the
codebase's poisoning recovery (`build_modules.rs`,
`pick_package.rs`, …): an unrelated panic shouldn't escalate into
a hard install failure since the guarded values are plain
collections with no invariants that survive a panic.

Side effects:

- `TreeCtx::snapshot` and `TreeCtx::resolved_versions` drop the
  `async` qualifier and their callers drop the `.await`. The
  closures they live in are still `async` (they await elsewhere),
  so the change is mechanical.
- `update_preferred_versions_with_ctx` becomes sync along with
  `resolved_versions`.

Tests: 50/50 in `pacquet-resolving-deps-resolver` pass. Clippy
clean.

… tree + graph nodes

`ResolveResult.clone()` ran at every visit in `resolve_node`
(into `ResolvedPackage.result`) and again per
`(dep_path, peer-suffix)` slot when `resolve_peers` carved the
graph nodes out of the resolved tree (into
`DependenciesGraphNode.resolve_result`). Both clones deep-copied
every `String` field on `ResolveResult` (`id`, `alias`,
`resolved_via`, `name_ver`, etc.) — 2× per resolved package ×
~1.3k packages = ~2.7k full struct clones on the resolve hot
path.

Wrap once at the resolver boundary so both stores share one
heap allocation:

- `ResolvedPackage.result` and
  `DependenciesGraphNode.resolve_result` re-typed as
  `Arc<ResolveResult>`.
- `resolve_node` wraps the resolver-returned `ResolveResult` in
  `Arc::new` once and uses `Arc::clone` for the store + later
  reads. The `extract_children` / `extract_peer_dependencies`
  borrows work unchanged via `Arc`'s `Deref`.
- `resolve_peers`'s `.clone()` of `pkg.result` is now an
  `Arc::clone` (refcount bump), not a deep copy.

Read sites in `dependencies_graph_to_lockfile` and
`install_with_fresh_lockfile` work unchanged — `&Arc<T>` derefs
to `&T` at the field-init coercion site and at every
`.field`-style access.

Tests: 348/348 in `pacquet-resolving-deps-resolver` +
`pacquet-package-manager` pass. Clippy clean.

…install bin linking

The fresh-lockfile install path was passing `None` for both
`snapshots` and `package_manifests` to `LinkVirtualStoreBins`,
falling back to the readdir-driven `run_with_readdir` that walks
`<virtual_store_dir>` (or `<store_dir>/links` under GVS) and reads
each child's `package.json` from disk per slot. The
warm-cache prefetch already pulled every snapshot's bundled
manifest out of the SQLite store index ([`PrefetchResult::manifests`]),
so the disk reads were redundant.

Wire the prefetched manifests through:

- Destructure `PrefetchResult` so `manifests` survives past the
  `await` (was being dropped on `let prefetched_cas_paths =
  prefetch.cas_paths`).
- Always build the freshly-resolved lockfile structure (was gated
  on GVS); both branches now reuse one `built_lockfile`. The build
  is ~3 ms on the alotta-files fixture and is what we save below
  anyway.
- Project `prefetched_manifests` (keyed by
  `<integrity>\t<pkg_id>`) into a `PackageManifests` map
  (`PkgNameVerPeer.without_peer() → Arc<Value>`) by walking the
  resolved graph and computing the cache key per node — same key
  shape as `pacquet_store_dir::store_index_key`.
- Drive `LinkVirtualStoreBins` with `snapshots: Some(...)` +
  `package_manifests: &map`; cold-batch packages (cache miss →
  downloaded fresh in this run) fall through to a per-child disk
  read just like before.

`packages: None` on purpose: the freshly-built lockfile's
`packages:` rows carry an incomplete `has_bin` because the
resolver's `PackageVersion` deserializer does not include the
`bin` field. Trusting the empty-by-omission `has_bin_set` here
would filter out every child and skip bin linking entirely.
Once `bin` is threaded through `PackageVersion`, the call site
can switch to `built_lockfile.packages.as_ref()` to recover the
~95% slot short-circuit the frozen-lockfile path enjoys.

Updated snapshots reflect the now-present
`<slot>/node_modules/<pkg>/node_modules/.bin/<pkg>` self-shim
the lockfile-driven path writes per pnpm's
`linkBinsOfDependencies`. The readdir path skipped it via
`link_bins_excluding` — that was the divergence the existing
`same_global_virtual_store_layout_*` parity tests called out;
the fresh path now matches.

…fetched hits

`run_with_mem_cache` was delegating to `run_without_mem_cache`, which
ran the prefetched-cas-paths check and returned the hit via
`(**cas_paths).clone()` — a deep clone of the inner
`HashMap<String, PathBuf>`. `run_with_mem_cache` then wrapped the
result in `Arc::new(...)`. On a warm install with 1k+ snapshots
that is one full per-file map allocation per snapshot, plus an Arc
allocation, when the prefetched `Arc<HashMap<...>>` is already on
hand.

Lift the prefetched-cas-paths check into `run_with_mem_cache` so a
hit returns `Arc::clone(prefetched_entry)` straight through and
populates `mem_cache` with the same Arc — no per-entry walk, no
fresh `Arc::new`. The inner check inside `run_without_mem_cache`
stays for the direct callers (binary / zip archive paths in
`install_package_by_snapshot`) that still want an owned `HashMap`
they can mutate (e.g. to splice in the synthesized
`package.json` for runtime archives).

Three small cleanups flagged on #11837:

1. `install_with_fresh_lockfile.rs` — the `drop(resolver);
   drop(npm_resolver);` block didn't actually free the resolver-side
   caches because the local `meta_cache`, `fetch_locker`, and
   `picked_manifest_cache` `Arc` bindings each still held one strong
   reference of their own. Drop those bindings explicitly too so the
   cache shrinks before the install pass starts pulling tarballs.

2. `resolve_dependency_tree.rs` — the doc comment on
   `resolve_dependency_tree` said later visitors "skip the
   recursion," but the `Some(existing)` branch only AND-folds the
   `optional` flag and the code then unconditionally allocates a
   fresh `DependenciesTreeNode` and recurses on the children.
   Reword the comment to match what the code actually does (only
   the `ResolvedPackage` envelope is shared).

3. `npm_resolver.rs` — `build_resolve_result` had 9 positional
   arguments under `#[allow(clippy::too_many_arguments)]`. Drop the
   suppression and take a `BuildResolveResult` struct instead so the
   three call sites read as named-field literals and adding a future
   field doesn't require touching every caller.