…m link phase via single rayon par_iter

Two structural changes that together cut warm-cache install wall time
on a 1352-package lockfile from ~10.85s to ~6.5s, beating pnpm v11
(~8.5s) by ~23% on the same machine.

1. `pacquet_tarball::prefetch_cas_paths` runs every store-index SELECT
   + integrity check the lockfile is going to need in one upfront
   `spawn_blocking` task, returning a `cache_key → cas_paths` map.
   `DownloadTarballToStore` now consults this map before falling
   through to its per-call `load_cached_cas_paths`. Eliminates the
   1352 separate `spawn_blocking` round-trips a warm install was
   doing — sample-profiling showed those each accumulating 20-60 ms
   of OS scheduling overhead while their actual work is sub-ms.

2. In `create_virtual_store::run`, partition snapshots into "warm"
   (prefetched) and "cold" (cache miss). The warm batch runs entirely
   on rayon via one big `par_iter` over the snapshot list — bypasses
   tokio futures, `try_join_all`, and per-snapshot `rayon::join`. The
   cold batch keeps the existing `try_join_all` + download path.

   Previously every per-snapshot tokio future called sync
   `rayon::join` from a tokio worker; with up to 10 such futures
   progressing concurrently and each one's inner par_iter saturating
   the rayon pool, the pool ended up processing one snapshot at a
   time despite tokio's worker count (`sum-of-link ≈ wall`, i.e.
   1× parallelism). Going straight to one big `par_iter` lets rayon
   schedule across all 1352 snapshots as one work-stealing graph,
   the shape pnpm's piscina pool gives implicitly.

Plus minor tuning: `crates/cli/src/lib.rs::configure_rayon_pool`
sizes the global rayon pool at `availableParallelism * 2`. The link
phase is dominated by `clonefile` syscalls that block on the kernel
metadata journal, not CPU; oversubscribing CPUs keeps more syscalls
in flight without losing wall time. Sweep on alot7: 4→9.5s, 10→9.4s,
20→9.25s, 50→9.42s, 100→10.2s — 2× was the knee. Honours an
explicit `RAYON_NUM_THREADS` override.

Verified `just ready` (typos / fmt / check / nextest / lint), and
that `pacquet install` produces an identical `node_modules` to pnpm
on the same lockfile (1495 package.json, 400M).

- Drop the store-index mutex between the SELECT loop and per-package
  integrity checks in `prefetch_cas_paths`. The original
  implementation held the lock across the whole batch, including the
  filesystem-bound `check_pkg_files_integrity` work; restructured so
  the lock is held only for the SELECTs.
- Wrap prefetched values in `Arc<HashMap<…>>`. The cold-batch fallback
  in `DownloadTarballToStore::run_without_mem_cache` previously had
  to deep-clone the per-file map on every prefetched hit to honour
  the function's owned-`HashMap` return type; cloning the `Arc` first
  drops that cost to one heap-allocation regardless of file count.
- Dedup `cache_keys` before calling `prefetch_cas_paths`. Lockfiles
  with peer-dependency variants of the same package collapse to one
  cache key (the key uses `metadata_key.without_peer()`), so the
  unsorted vec was making the prefetch redo identical SELECT +
  integrity-check work for every variant.
- Add a unit test for the prefetched short-circuit:
  `reuses_prefetched_cas_paths_when_provided` proves
  `run_without_mem_cache` returns the prefetched map without touching
  SQLite or the network.
- Doc fix: the rayon-pool comment said `2 × availableParallelism`
  but the code uses `num_cpus::get()`. Reword to match the
  workspace's existing `num_cpus` convention (e.g.
  `tarball::post_download_semaphore`).

- `(**cas_paths).clone()` in the cold-fallback path is a deep clone of
  the per-file `HashMap`, not an `Arc::clone`. Reword the comment to
  match: the `Arc` wrapping in `PrefetchedCasPaths` saves the deep
  clone on the new warm-batch path (which uses `cas_paths.as_ref()`),
  not on this fallback path. Propagating the `Arc` through
  `DownloadTarballToStore::run_without_mem_cache`'s return type would
  be a wider refactor.
- Gate the warm-batch `par_iter` on `tokio::task::block_in_place`
  when running on a multi-thread runtime, falling back to a plain
  inline call on `current_thread`. The previous unconditional
  `par_iter` from inside an `async fn` blocked one tokio worker for
  the whole warm batch — fine on the production multi-thread
  runtime, but on a 2-core / 2-worker runtime it would halve async
  progress for the rest of the install. `block_in_place` migrates
  any other futures off the calling worker first, but it panics on
  `current_thread` (which is what `#[tokio::test]` uses by default),
  so the flavor check keeps the existing test suite working.
- Switch `configure_rayon_pool` from `num_cpus::get()` to
  `std::thread::available_parallelism()`. `num_cpus` reports the
  host's logical CPU count regardless of cgroup / CPU-quota limits,
  which on a quota-limited runner could spin up more rayon threads
  than the kernel will actually schedule onto our cores. Drop the
  `num_cpus` dep from `pacquet-cli` since this was its only use.

- Extract `snapshot_cache_key` helper for the `(integrity, pkg_id)`
  → cache-key derivation. Both call sites (the upfront
  `cache_keys` build and the warm/cold partition loop) now go
  through the same helper, so a future change to the resolution-type
  handling or key shape stays in one place. A drift between the two
  loops would silently misclassify warm entries as cold and quietly
  halve install speed.
- Document the intentional `.max(4)` floor in `configure_rayon_pool`.
  Even on a quota-limited 1-2-CPU runner, dropping below 4 puts
  rayon back into the regime where one thread blocks on `clonefile`
  while the next ready snapshot can't start; the metadata-journal
  bottleneck doesn't shrink with quota, so a small intentional
  oversubscription is the better trade. Both the function-level doc
  and an inline comment by the `.max(4)` call explain the choice.

Previously `CreateVirtualStore::run` walked `snapshots` twice and
called `snapshot_cache_key` on each pass — once to build the deduped
prefetch input, once to partition warm vs cold. Each call allocates
two strings (the integrity copy and the `format!`-built cache key),
so the second walk was paying ~2 × snapshots × {2 String allocs} for
no benefit.

Single-pass shape:

  1. Walk `snapshots` once, build a `Vec<(snapshot_key, snapshot,
     Option<String>)>` that owns the per-snapshot cache key.
  2. Collect deduped `&str` refs into a `Vec<&str>`, sort + dedup,
     then collect to owned `String` for the prefetch boundary —
     so the prefetch input contains one `String` per *unique* key
     rather than one per snapshot (peer-variant lockfiles already
     gave us cheap dedup; this also removes the dedup-stage clones).
  3. Partition by re-using the stashed `Option<String>` on each
     entry: a `cache_key.as_deref().and_then(|k| prefetched.get(k))`
     lookup, no key recomputation.

Net: one `snapshot_cache_key` call per snapshot (was two), and the
prefetch sees a deduped owned `Vec<String>` of size
`unique_cache_keys` (was `snapshots.len()` before its own internal
sort/dedup). Bench is unchanged within noise on the alot7 sandbox
(~6.18 s warm); the win is allocation pressure on huge lockfiles
where peer-variant duplication is high.

Copilot follow-up review on #292.

- Move `configure_rayon_pool` to after `CliArgs::parse()`. clap's
  `--help` / `--version` paths exit inside `parse`, so they never
  reach the rayon pool init now — `pacquet --help` no longer
  spawns worker threads it'll throw away. Other subcommand paths
  still pay the (small) init cost; we can move it into the install
  path specifically as a follow-up if non-install commands are
  ever added that don't need rayon.
- Drop the local `CasPathsArc` / `WarmEntry` aliases in
  `create_virtual_store::run`. They duplicated the value type of
  `pacquet_tarball::PrefetchedCasPaths`; if that map's value type
  changes, the local aliases would silently drift. Letting `warm`'s
  element type be inferred from its `push` calls keeps the binding
  to the upstream type.
- Add three unit tests for `prefetch_cas_paths`:
    * `prefetch_cas_paths_returns_hits_for_live_index_rows` — happy
      path: index row written, CAFS blob present, verify on; result
      contains the expected file map.
    * `prefetch_cas_paths_omits_failed_integrity_entries` — index
      row whose digest matches no on-disk file; verify on; row is
      dropped from the result rather than surfacing a half-populated
      map.
    * `prefetch_cas_paths_skips_filesystem_checks_when_verify_disabled`
      — same shape as the failing-integrity test but with
      `verify_store_integrity = false`; the row surfaces (no fs
      checks), matching pnpm's `verify-store-integrity: false`
      semantics.

Change `snapshot_cache_key` from `Option<String>` to
`Result<Option<String>, CreateVirtualStoreError>`:

- Missing metadata, missing tarball integrity, and currently-
  unsupported `directory` / `git` resolutions all return `Err(...)`
  with the same error variants the cold batch's
  `InstallPackageBySnapshot::run` would surface anyway.
- `Ok(Some(key))` for valid tarball / registry resolutions (today
  the only shape that participates in the CAFS prefetch).
- `Ok(None)` is reserved for any future legitimate non-CAFS
  resolution variant, so adding one later doesn't force a wider
  refactor.

The orchestrator validates every snapshot before starting the warm
batch — `snapshot_entries` is built with `.collect::<Result<_, _>>()?`
— so a malformed lockfile fails immediately instead of after the
~6-second warm rayon batch. Previously those snapshots were
collapsed into `None` and shoved into the cold batch, which only
runs *after* warm completes; the same error fired but the user
waited through a wasted warm phase first (Copilot review on #292).