…uet (pnpm#11684)

* fix(fs,package-manager): match upstream symlink-dir semantics

`pacquet_fs::symlink_dir` was a thin wrapper over the platform syscall
and diverged from pnpm's [`symlink-dir`](https://github.com/pnpm/symlink-dir)
npm package (v10.0.1) in three user-visible ways:

1. Unix symlinks stored the absolute target. Upstream writes the target
   as a path relative to the link's parent dir
   (`path.relative(dirname(link), src)`), so installs survive a project
   move and on-disk symlink contents match pnpm's byte-for-byte.
2. Windows always created junctions. Upstream tries a true directory
   symlink first and only falls back to a junction on
   `ERROR_PRIVILEGE_NOT_HELD`. Dev-Mode / Administrator users get a
   true symlink with pacquet now too. The choice is cached
   process-wide via `AtomicU8` so subsequent calls skip the EPERM
   probe, mirroring upstream's binding-rebind.
3. The library default `{ overwrite: true }` retargets stale links and
   moves non-symlink occupants to `.ignored_<basename>`. Pacquet only
   exposed the bare primitive, so `symlink_package` (the direct-dep
   linker, equivalent to pnpm's `symlinkDependency`) silently swallowed
   `AlreadyExists` — re-installs that retargeted a dependency left the
   stale link in place.

Adds `force_symlink_dir` and `ForceSymlinkOutcome` to `pacquet_fs`
porting upstream's `forceSymlink` flow: mkdir-on-`NotFound`, reuse on
matching target, unlink-and-retry on stale link, rename-to-`.ignored_*`
on non-symlink occupant (with the macOS unlink fallback on the second
attempt, per pnpm#5909). `symlink_package` calls it.

Existing call sites that intentionally use `{ overwrite: false }`
semantics (`hoist::symlink_hoisted_dependencies`, the
`register_project` heal path) stay on the bare `symlink_dir` primitive.

Tests:
- New tests in `pacquet/crates/fs/src/symlink_dir/tests.rs` cover the
  relative-target encoding, idempotent re-symlink, stale-link retarget,
  occupant rename, and missing-parent mkdir.
- Updated `create_symlink_layout/tests.rs`,
  `install_package_from_registry/tests.rs`, and `install/tests.rs` to
  compare against the relative encoding (via `pathdiff` /
  `canonicalize`) instead of the prior absolute string.

---
Written by an agent (Claude Code, claude-opus-4-7).

* test(cli,store-dir): adapt remaining symlink assertions to relative encoding

CI surfaced two more test sites that compared `fs::read_link` /
`dunce::canonicalize(read_link_output)` against the absolute target
path. Those resolved fine when pacquet wrote absolute symlinks but
fail now that the symlink contents are stored as paths relative to
the link's parent (matching upstream `symlink-dir`).

Canonicalize via the symlink path itself so the kernel resolves the
relative target, the same fix already applied to the
`package-manager` tests in the previous commit.

- `pacquet/crates/cli/tests/add.rs::should_symlink_correctly`
- `pacquet/crates/store-dir/src/project_registry.rs::register_creates_symlink_to_project_dir`

---
Written by an agent (Claude Code, claude-opus-4-7).

* fix(fs): satisfy dylint perfectionist lints in symlink_dir

CI's `cargo dylint --all -- --all-targets --workspace` flagged two
multi-line macro invocations missing a trailing comma:

- `format!` in the mkdir-error wrapping branch (line 163).
- `matches!` over the rename-overwrite occupied-kind set (line 271).

Both surfaced under `-D warnings` via
`perfectionist::macro-trailing-comma`. Added the trailing commas;
local `cargo check -p pacquet-fs` is clean.

---
Written by an agent (Claude Code, claude-opus-4-7).

* fix(fs): drop trailing commas on collapsed single-line asserts

`cargo fmt` collapsed five multi-line `assert!` calls in
`symlink_dir/tests.rs` to single lines but left the trailing comma
intact. Dylint's `perfectionist::macro-trailing-comma` rejects the
single-line-with-trailing-comma shape under `RUSTFLAGS=-D warnings`.

Removed the commas. `cargo test -p pacquet-fs` still passes.

---
Written by an agent (Claude Code, claude-opus-4-7).

* test(testing-utils): recognize true symlinks in is_symlink_or_junction

The helper has always claimed to detect "symlink or junction" but
only called `junction::exists` on Windows, which checks the
`IO_REPARSE_TAG_MOUNT_POINT` reparse tag. With pacquet's symlink
writer now trying a true directory symlink first on Windows (and
only falling back to a junction on `PermissionDenied`), Windows
runners that have `SeCreateSymbolicLinkPrivilege` enabled —
including GitHub Actions `windows-latest`, which runs as
Administrator with Developer Mode on — get a true symlink at
`IO_REPARSE_TAG_SYMLINK`. The old helper returned `false` for those,
which fooled `should_install_dependencies` and
`install_resolves_env_var_in_npmrc_registry` into thinking the
install hadn't produced any symlink at all.

Combine `junction::exists` with `Path::is_symlink` so the helper
matches its name. No change on Unix.

---
Written by an agent (Claude Code, claude-opus-4-7).

* fix(testing-utils): drop needless return in is_symlink_or_junction

Clippy's `needless_return` (denied under `-D warnings` on the Windows
`Clippy` step) flagged the trailing `return Ok(path.is_symlink())`
inside the `#[cfg(windows)]` block I added in the previous commit.
Fold the junction-or-symlink check into a single boolean expression
so each cfg branch ends with the result directly.

---
Written by an agent (Claude Code, claude-opus-4-7).

* fix(fs): write relative target for Windows true symlinks too

Upstream `symlink-dir`'s `resolveSrcOnTrueSymlink` (which feeds the
`fs.symlink(target, path, 'dir')` call) runs on both Unix and Windows
and always passes the path-relative-to-dirname target. The Windows
junction path takes the absolute target with a trailing backslash
instead, but the `junction` crate handles that wrapping internally.

Pacquet's Windows branch was calling
`std::os::windows::fs::symlink_dir(original, link)` with the absolute
target, which diverged from pnpm on hosts that have
`SeCreateSymbolicLinkPrivilege` (GitHub Actions Windows runners do —
they run as Administrator with Developer Mode on) and tripped the
two `create_symlink_layout` parity tests on Windows CI:

    Diff < left / right > :
    <"C:\\...\\.tmpdluV0r\\string-width@4.2.3\\node_modules\\string-width"
    >"..\\..\\string-width@4.2.3\\node_modules\\string-width"

Lift the existing Unix helper `relative_target_for` out of its
`cfg(any(unix, test))` gate so the Windows symlink branch can call
it too, and route both the cached `USE_SYMLINK` path and the
probe-and-cache path through a new `create_true_symlink` helper
that computes the relative form before the `CreateSymbolicLinkW`
syscall. The junction branch keeps the absolute `original`.

---
Written by an agent (Claude Code, claude-opus-4-7).