Ports `makeEnv` and the surrounding env block from `@pnpm/npm-lifecycle`
at `d2d8e790` (`index.js:73-104`, `:354-414`) plus the pnpm-side
wrapper's `extraEnv` additions at `pnpm/exec/lifecycle/src/runLifecycleHook.ts:119-124`
(pinned to `b4f8f47ac2`).

Lifecycle scripts now see:

- `npm_lifecycle_event`, `npm_lifecycle_script`
- `npm_node_execpath` / `NODE` (resolved against `PATH` when not supplied)
- `npm_package_json`, `npm_execpath`
- `npm_package_*` for `name`, `version`, and every key under `config`,
  `engines`, `bin` (filter mirrors `index.js:380-385`; multi-line
  values JSON-encode at `:406-408`)
- `npm_config_node_gyp`, `npm_config_user_agent` when supplied
- `INIT_CWD`, `PNPM_SCRIPT_SRC_DIR`
- `TMPDIR` under `<wd>/node_modules/.tmp` when `unsafe_perm` is false
  (created on disk; `EEXIST` is tolerated)

The spawn now strips inherited env via `env_clear()` so leftover
`npm_*` / `pnpm_*` keys from a wrapping invocation cannot leak
through, matching `makeEnv`'s `!i.match(/^npm_/)` filter at
`index.js:358-362`.

`RunPostinstallHooks` grows `node_execpath`, `npm_execpath`,
`node_gyp_path`, `user_agent`, and `unsafe_perm` fields. The
`BuildModules` caller passes `None`/`true` for all of them — the
`unsafePerm` plumbing is item #14 in #397.

Tests port the upstream `test('makeEnv')` invariants and add an
end-to-end check that a spawned child sees the stamped variables
and does NOT see leaked `npm_config_*` keys (adapted from
`pnpm/exec/lifecycle/test/index.ts:65-77` using a file-dump model
rather than an IPC fixture).

CI surfaced two classes of issue on the new lifecycle modules:

- `dylint` (perfectionist macro-trailing-comma) flagged five
  `assert*!`/`format!` sites where `cargo fmt`'s rewraps left the
  invocations in the disallowed shape: trailing comma on a
  single-line macro, missing trailing comma on a multi-line one.
- `rustdoc -D warnings` rejected a Windows-only intra-doc link to
  `std::os::windows::process::CommandExt::raw_arg` (the path
  doesn't resolve on non-Windows targets where docs build) and a
  redundant explicit `[`build_env`](crate::build_env)` target.

Pure lint fixes — no behavior or test-coverage change. Tests
still pass and `RUSTDOCFLAGS=-D warnings cargo doc` is clean for
`pacquet-executor`.

The Windows CI runner caught two test-only Windows regressions
introduced by the shell-selection change earlier in this branch:

- `extend_path::tests::pnpm_virtual_store_layout_yields_three_bins_deepest_first`
  hard-coded `/proj/...` expected values. `path::absolute("/proj")`
  on Windows resolves against the current drive (`C:\proj`), making
  those expectations racy with the runner. Split into a Unix-gated
  test with literal expectations and a new platform-neutral test
  that asserts the structural invariants (count + deepest-first
  ordering) without anchoring to any absolute root.
- `lifecycle::tests::lifecycle_emits_script_stdio_and_exit_in_order`
  and the new `child_sees_stamped_npm_package_and_no_leaked_npm_config`
  both use POSIX-only script syntax (`;`, `1>&2`, `printf`, `$VAR`).
  Before this branch the spawn used a hard-coded `sh -c` so Git
  Bash on the Windows runner satisfied them; once the shell
  selector started picking `cmd /d /s /c` on Windows (per item #4
  / parity with pnpm) those tests can no longer run there. Gate
  them on `cfg(unix)`. The cmd-path shell selection itself is
  covered by `crate::shell` unit tests; env stamping by
  `crate::make_env` units.

No production-code change.

Two more Windows-only test regressions slipped through the previous
pass:

- `make_env::tests::make_env_stamps_lifecycle_specific_keys` and
  `make_env::tests::make_env_tmpdir_gating_mirrors_unsafe_perm`
  hard-coded forward-slash expected values for `npm_package_json`,
  `INIT_CWD`, `PNPM_SCRIPT_SRC_DIR`, and `TMPDIR`. On Windows
  `Path::join` emits `\` separators, so the assertions break. Build
  expected values through the same `Path::join` path so separator
  handling stays `std`'s problem, not the test's.
- `extend_path::tests::virtual_store_walk_orders_deepest_first`'s
  multi-line `assert!` collapsed to single-line-plus-trailing-comma
  under `cargo fmt`, which the dylint `perfectionist` rule rejects.
  Drop the trailing comma so fmt and dylint agree.

Five production-code fixes and three test-quality fixes from
Copilot + coderabbit on PR #418:

- `is_stamping_key` narrowed from `npm_* | pnpm_*` to just `npm_*`,
  matching upstream's `!i.match(/^npm_/)` at `npm-lifecycle/index.js:359`.
  Dropping every `pnpm_*` key would have stripped `PNPM_HOME` and
  feature flags upstream preserves.
- `find_node_in_path` no longer reads the process-global `PATH` via
  `env::var_os`. It now takes the parent env's PATH as a parameter,
  so `build_env` is fully deterministic given its inputs (matching
  the docstring contract).
- Look up `PATH` from `parent_env` case-insensitively via a new
  `path_value` helper. Windows preserves the system casing
  (typically `Path`) on env keys, so the previous `built.env.get("PATH")`
  call returned `None` there and `extend_path` lost the inherited
  system PATH.
- `run_postinstall_hooks` captures the parent env once and threads it
  through to each lifecycle hook, instead of calling
  `env::vars().collect()` from inside `run_lifecycle_hook` on every
  hook spawn. The three hooks for one package now observe a
  consistent snapshot.
- TMPDIR creation drops the `AlreadyExists`-swallow special case.
  `fs::create_dir_all` returns `Ok(())` when the path already exists
  *as a directory*; `AlreadyExists` from it specifically signals a
  non-directory file at that path, which is a real error that
  should surface as a spawn failure.

Test fixes:
- `child_sees_stamped_npm_package_and_no_leaked_npm_config` now
  installs a `Drop`-based env guard around the `set_var` call, so
  an assertion failure cleans up the seed instead of leaking it
  into sibling tests. Stray `dbg!(dump)` removed; bare `assert!(ran)`
  picks up a diagnostic message.
- `make_env_stamps_top_level_keys_and_strips_npm_config_leakage`
  swapped the `pnpm_config_user_agent`-must-be-stripped assertion
  for a `PNPM_HOME`-must-pass-through assertion. Mirrors the
  narrowed filter and the upstream behavior.

Rust's `Command::env` treats env keys case-insensitively on Windows.
Combined with our case-sensitive filter, a parent env containing
e.g. `NPM_CONFIG_FOO` (uppercase) would pass through unfiltered;
when we then inserted `npm_lifecycle_event` and friends, the spawn-
side env block would carry both casings of the same Windows-logical
variable, with the surviving value picked unpredictably from
HashMap iteration order.

Make `is_stamping_key` take an explicit `is_windows: bool` and use
`eq_ignore_ascii_case` for the prefix and exact-match arms on
Windows. Production callers pass `cfg!(windows)`; tests cover both
branches.

Coverage:
- POSIX path: matches `/^npm_/` literally; `Node`, `NPM_CONFIG_*`,
  etc. all survive (they're distinct variables on POSIX).
- Windows path: strips any-case `npm_` prefix and `NODE` / `TMPDIR` /
  `INIT_CWD` / `PNPM_SCRIPT_SRC_DIR` exact-matches in any case.
- `PNPM_HOME` and other `pnpm_*` keys still pass through on both
  platforms — they're not in upstream's strip set.

The `// Item #14 will replace this …` / `// Item #15 in #397 …`
comments referenced specific items in the audit issue this PR
partially closes. Per `CLAUDE.md`:

  Don't reference the current task, fix, or callers ("used by X",
  "added for the Y flow", "handles the case from issue #123"), since
  those belong in the PR description and rot as the codebase evolves.

Replaced the substantive WHY (placeholder default until config is
plumbed) without naming the issue, and dropped the comments that
were just restating the field name. Same applies to the
`RunPostinstallHooks.unsafe_perm` doc comment.

Three issues raised by Copilot on the case-insensitive filter
commit:

- `is_stamping_key` previously did `key[..4].eq_ignore_ascii_case(...)`
  on the Windows branch. That can panic when `key` is non-ASCII and
  byte 4 lands inside a multi-byte codepoint (e.g. `"x\u{10000}"`
  is 5 bytes with a 4-byte codepoint starting at byte 1). Switched
  to a byte-level prefix check via `key.as_bytes().get(..4)`, which
  short-circuits on non-ASCII keys without panicking. Added a
  regression test covering the panic-y inputs.
- `run_lifecycle_hook` previously called `.envs(&built.env).env("PATH", ...)`,
  relying on `Command::env`'s case-insensitive dedup on Windows to
  beat the inherited `Path` key. The dedup behavior is real (and
  documented), but relying on it leaves an unspecified-winner edge
  case visible to the spawned process. Strip any PATH-like key
  from the env map case-insensitively before inserting our
  computed `PATH`, so the spawn sees exactly one PATH slot.
- `ancestor_node_modules_bins` previously fell back to an empty
  `PathBuf` when `head` was empty (i.e. `wd` starts with
  `node_modules/`). Upstream's `path.resolve("")` returns the
  process cwd; switch to `env::current_dir()` for that case to
  match. Added a code comment so the cwd-dependence isn't
  surprising — pacquet's production call sites always pass an
  absolute `pkg_root`, so the dependency is a non-issue in
  practice, but matching upstream removes the divergence.

Copilot flagged that `env::join_paths` errors when any path
component contains the platform separator, and my fallback
discarded every computed entry — `.bin` walk, node-gyp shim,
extra paths — leaving lifecycle scripts with only the inherited
PATH (or empty). Upstream's
`pathArr.join(process.platform === 'win32' ? ';' : ':')` at
`lib/extendPath.js:26` does an unvalidated string join; if a
component contains the separator, the spawned shell sees an
embedded extra entry, which is the same outcome upstream
produces.

Replaced `env::join_paths` with a tiny `join_paths_lossy` helper
that does the literal string join, matching upstream exactly.
Added a POSIX-gated regression test (`separator_in_path_component_does_not_drop_other_entries`)
that exercises an `extra_bin_paths` component containing `:` and
asserts both the wd `.bin` and the weird extra path survive.