Mirrors pnpm v11's `@pnpm/bins.resolver`, `@pnpm/bins.linker`, and
`@zkochan/cmd-shim` (resolved at pnpm `4750fd370c` and cmd-shim
`0d79ca9534`):

- New `pacquet-cmd-shim` crate parses the `bin` field of a package
  manifest, resolves bin commands with the same path-traversal and
  URL-safe-name guards as upstream, and writes Unix shell shims
  byte-compatible with pnpm's `generateShShim`. Conflict resolution
  follows `pkgOwnsBin` + lexical compare.
- New `LinkVirtualStoreBins` step walks each virtual-store slot and
  links its child packages' bins into the slot's own
  `node_modules/.bin`, matching `linkBinsOfDependencies` in pnpm's
  `building/during-install`.
- `SymlinkDirectDependencies` and `InstallWithoutLockfile` now call
  the bin linker after the symlink layout is in place, so direct deps'
  bins land under `<modules_dir>/.bin/`.

Per `plans/TEST_PORTING.md` "Link Dependency Binaries", this is the
direct-dependency-bins-first slice. Hoisted-bin precedence,
`directories.bin` discovery, lifecycle-script-created bins, and
Windows `.cmd`/`.ps1` shims are deferred.

The link triggered `rustdoc::private_intra_doc_links` under
`-D warnings` (the Doc CI job), which fails CI. Replace with plain
backticks since the function is intentionally private.

The integrated benchmark on the 1267-package fixture showed a ~4-12%
regression vs. main on both `Frozen Lockfile` and
`Frozen Lockfile (Hot Cache)` after introducing bin linking. Each
virtual-store slot's bin walk was running serially:

- `LinkVirtualStoreBins::run` did `read_dir + is_dir` per slot inside
  a serial `for` loop. With ~1300 slots in the benchmark, the per-slot
  syscall overhead alone accounted for most of the new wall time.
- `link_bins_of_packages` wrote every shim (read shebang, write file,
  chmod) on the calling thread.
- `collect_bin_sources` (direct deps) read every dependency's
  `package.json` serially.

All three loops are work-list shaped with no shared state, so drive
them on rayon. Mirrors the per-snapshot warm batch in
`create_virtual_store.rs` and pnpm's own `Promise.all`-style fan-out
in `linkBinsOfDependencies`.

Per CODE_STYLE_GUIDE.md "Unit test file layout": once a `mod tests`
block is long enough to obscure the surrounding module, it moves to
`<parent>/tests.rs`. The four test blocks introduced for bin linking
(78-130 lines each) were past that threshold.

Moved:
- crates/cmd-shim/src/bin_resolver.rs       -> .../bin_resolver/tests.rs
- crates/cmd-shim/src/shim.rs               -> .../shim/tests.rs
- crates/cmd-shim/src/link_bins.rs          -> .../link_bins/tests.rs
- crates/package-manager/src/link_bins.rs   -> .../link_bins/tests.rs

No test logic changed.

`Path::is_absolute("/abs/elsewhere/cli")` returns true on Unix but
false on Windows (Windows requires a drive letter), so the test forced
the wrong branch on Windows CI. The absolute-vs-relative classification
of shim targets is itself platform-dependent; pin the test to Unix
only.

Closes the rest of the bin-resolver / cmd-shim feature parity gap with
pnpm v11 within this PR's scope.

- \`directories.bin\` fallback (\`bin_resolver.rs\`):
  walkdir over every regular file under the package's nominated dir,
  with the same \`is_subdir\` traversal guard pnpm uses. Missing dir
  degrades to an empty list. Ports five upstream tests:
  index.ts:37 / :150 / :160 + path-traversal.test.ts.

- Windows \`.cmd\` and \`.ps1\` shim generation (\`shim.rs\`):
  ports \`generateCmdShim\` and \`generatePwshShim\` from
  @zkochan/cmd-shim 0d79ca9534. CRLF line endings on the .cmd flavor;
  \$basedir+\$exe header on the .ps1 flavor with Windows/POSIX-pwsh
  detection. Both exec arms (with-prog / no-prog) ported. Skips the
  \`nodeExecPath\` / \`nodePath\` / \`prependToPath\` / \`progArgs\`
  branches we don't use.
- \`link_bins.rs\` writes all three shim flavors per bin so a project
  installed on Linux remains usable on Windows after a clone. Idempotent
  short-circuit only fires when the canonical .sh shim already points
  at the same target.

- Extract \`symlink_direct_deps_into_node_modules\` from
  \`SymlinkDirectDependencies::run\`. Same shape as the
  \`link_direct_dep_bins\` extraction this PR already does — closes
  the unit-test gap that codecov flagged at 44.11% on
  symlink_direct_dependencies.rs without needing the mock-registry
  scaffold.

Test count: cmd-shim 49 → 59, package-manager (lib) 35 → 37.

…main neutrality

Renames the generic parameter and concrete provider type from \`Fs\`/
\`RealFs\` to \`Api\`/\`RealApi\` across pacquet-cmd-shim and the
pacquet-package-manager call sites. Also renames the module
\`fs_capabilities.rs\` -> \`capabilities.rs\`.

The trait names keep their \`Fs\` prefix (\`FsReadDir\`, \`FsReadFile\`,
\`FsReadString\`, \`FsReadHead\`, \`FsCreateDirAll\`, \`FsWriteAtomic\`,
\`FsSetPermissions\`) — domain prefixes belong on traits, not on the
provider.

Reasoning, per the revised DI reference at
#332 (comment 4345054524):

The reference uses \`RealApi\` to model a single provider that
implements every capability the install pipeline needs, regardless
of domain. Crates that today only have fs-side capabilities (this
one, modules-yaml) will likely cross domains in the next milestones
— lifecycle scripts need \`GetNodeExecPath\` or similar, fixture-
based install tests need \`GetCurrentTime\` for \`prunedAt\`. Doing the
rename now avoids a churning rename when the first non-\`Fs*\`
capability lands.

No semantic changes; tests all still pass (cmd-shim 69, package-
manager-lib 38).

The latest revision of the DI reference comment
(#332 issuecomment-4345054524) added principle 6:

> Provider names are domain-neutral; trait names are domain-scoped.
> The generic and its production impl are \`Api\` and \`RealApi\`
> regardless of how many domains they cover.

That principle is about the *production* provider. Test fakes
follow a different rule the same revision spells out:

> Test fakes describe what behaviour they fake, not their provider role.

The upstream example (\`BadYamlFs\`) names a single-trait fake by
behaviour + domain of the trait it fakes. My earlier rename had
turned \`PermissionDeniedFs\` / \`EmptyReadFs\` into
\`PermissionDeniedApi\` / \`EmptyReadApi\` — that was wrong: those
fakes implement only \`FsReadHead\`, not the full provider role,
so the \`Api\` suffix overstates what they do. Revert to the
behaviour+domain shape that matches \`BadYamlFs\`.

Multi-trait fakes (\`FailingProbe\`, \`DenyManifestRead\`, etc.)
already follow behaviour-only naming and don't need a domain
suffix — they describe the failure scenario directly.

Two doc fixes from the Copilot review on PR #333
(pullrequestreview-4267779783 / -4267945452):

1. `normalize_bundled_manifest` claimed `{ name, version }`-shaped
   manifests typically return `None` because those fields are "NOT
   in the pick list". Wrong on both counts: `name` is in
   `BUNDLED_MANIFEST_FIELDS` and `version` is special-cased first.
   A real npm-published `package.json` always carries both, so the
   typical case is `Some(...)`, not `None`. Updated to describe
   when `None` actually fires (non-object input, all fields
   absent or `null`).

2. `PrefetchedManifests` claimed `None` entries are stored to
   distinguish "no manifest stored" from "package wasn't prefetched
   at all", but the type is `HashMap<String, Arc<Value>>` — there's
   no way to express `None`. Rewrote: a missing key is either
   case, and callers cross-reference with [`PrefetchedCasPaths`]
   from the same [`PrefetchResult`] when they need to tell them
   apart.

No code change.

Two fixes from CodeRabbit's full review on PR #333 (review
4267999547 at 23:23):

1. **Restore the slot's-own-pkg-dir probe in the readdir
   fallback** (`r3222744362`). The lockfile-driven path doesn't
   need it because `create_virtual_dir_by_snapshot` enforces the
   `<slot>/node_modules/<pkg>` invariant before bin-linking — that
   was the rationale for dropping the probe in 6e079bf (1267
   wasted readdirs on warm install). The readdir fallback path
   (`InstallWithoutLockfile` only) has no such guarantee: if a
   slot's `node_modules/<pkg>` is missing but sibling deps are
   still present, `link_bins_excluding` would `create_dir_all` the
   phantom `<pkg>` chain to hold shims, leaving an orphan package
   directory on disk. Re-add `Api::read_dir(&self_pkg_dir).is_err()`
   gating before calling `link_bins_excluding` *only* in this
   fallback path — visits ~direct-deps slots (small N), so the
   probe cost is trivial here.

2. **Surface non-`NotFound` errors on scope read_dir**
   (`r3222744370`). `link_bins_excluding` was swallowing every
   error on `Api::read_dir(<scope-dir>)` with a bare
   `let Ok(...) else continue`. A `PermissionDenied`, `EIO`, or
   AppArmor deny there would silently drop every bin under the
   scope. Match the `NotFound`-only-skip pattern the rest of the
   file uses (`modules_dir` read, manifest read).

All 13 link_bins tests still pass. fmt + clippy clean.

The doc comment I added in 1e3232e linked `[\`parse_shebang\`]` from
`parse_shebang_from_bytes` (public) to `parse_shebang` (private),
which trips `rustdoc::private_intra_doc_links` under `-D warnings`
when CI runs `cargo doc` *without* `--document-private-items`. The
link only resolved because my local run used the private-items
flag.

Replace the intra-doc link with plain backticks. Same meaning to
the reader, no broken rustdoc target.

Two Copilot findings on the latest review:

1. **Bundled manifest must be last-wins on duplicate `package.json`
   tar entries** (`r3222807498`). pnpm's `addFilesFromTarball` at
   [`store/cafs/src/addFilesFromTarball.ts:41-43`](https://github.com/pnpm/pnpm/blob/4750fd370c/store/cafs/src/addFilesFromTarball.ts#L41-L43)
   unconditionally re-assigns `manifestBuffer = fileBuffer` on every
   `package.json` entry — same overwrite semantics as
   `filesIndex.set(...)`, so `manifest` and `files` stay consistent
   when a tarball publishes duplicate paths. Pacquet was first-wins
   via `pkg_files_idx.manifest.is_none()`, so a divergent later
   `package.json` would leave a stale earlier manifest in the index
   row. Drop the guard, parse + assign on every `package.json`
   entry, clear to `None` on parse failure (matches pnpm's "parse
   once at end, undefined on failure" via early degrade).

2. **`unfiltered = has_bin_set.is_empty()` conflated two
   semantically different cases** (`r3222807548`):
   - lockfile `packages:` section missing — we have no info,
     fall back to processing all children.
   - lockfile present but no entry has `hasBin: true` — the
     lockfile *says* no package has a bin and every slot should
     short-circuit.
   Pnpm's filter at `during-install/src/index.ts:283` returns
   `dep.hasBin && dep.installable !== false`; on a lockfile with
   no `hasBin: true` entries pnpm rejects every child. Change
   `build_has_bin_set` to return `Option<HashSet<PackageKey>>`:
   `None` = info absent (process all), `Some(set)` = info present
   and authoritative (filter via the set, even when empty).

All 444 workspace tests pass.