Ports pnpm v11's `writeFileExclusive` shape (`store/cafs/src/writeFile.ts:21-28`
and the `EEXIST` branch in `writeBufferToCafs.ts:57-68`) into pacquet's
CAFS writer. The old shape paid a `file_path.exists()` stat on every
call before the open; on a cold install where essentially every CAS
file is new the stat always returned `false`, so it was pure waste.

Replace it with `OpenOptions::create_new(true)` (`O_CREAT|O_EXCL` on
Unix, equivalent disposition on Windows) and map `ErrorKind::AlreadyExists`
to `Ok(())`. The warm-cache case (file already at its hash-derived
path) and the concurrent-writer race (another install process on the
same store got to this entry first) are both correct no-ops because
the path itself is the integrity assertion — contents at `files/XX/…`
are by definition the sha512 digest recorded in the filename, so a
present file has the bytes we were about to write.

pnpm still stats first because it runs `verifyFileIntegrity` on the
existing file to detect torn mid-write blobs from a crashed prior
install; pacquet doesn't re-verify individual CAS files on write (the
tarball-level ssri check has already passed for the batch these bytes
came from), so the stat has no job to do and can go. Torn-blob recovery
remains an open concern tracked in `investigations/pacquet-macos-perf.md`
§5 — the fix there is temp+rename, orthogonal to this syscall shape.

Also flips `ensure_file` from the pre-PR `OpenOptions::create(true)`
(which silently overwrites) to `create_new(true)` (refuses to
overwrite, surfaces as AlreadyExists → Ok). A concurrent writer now
can't silently clobber our partially-written bytes, which is a
strictly better safety property even though the observable behavior
doesn't change on success paths.

Adds four targeted tests pinning:
- new-file write puts bytes on disk (with mode on Unix);
- pre-existing file is preserved byte-for-byte (not overwritten);
- missing parent dir surfaces as CreateFile/NotFound so callers
  can't accidentally bypass the `ensure_parent_dir` contract.

First pass of this PR skipped integrity verification on the
`AlreadyExists` branch on the theory that the hash-derived CAS path
itself is enough of an assertion. That misses torn-blob recovery —
a prior install that crashed mid-write leaves a file at the right
path with wrong bytes, and a new install would happily skip over it,
silently serving corrupt bytes downstream.

Port pnpm v11's `writeBufferToCafs` full shape instead:

1. `O_CREAT|O_EXCL` open (unchanged from first pass) — success means
   we wrote the bytes ourselves.
2. `AlreadyExists` → re-read the file and byte-compare with `content`.
   CAS paths are hash-derived, so matching bytes imply matching digest;
   this is pnpm's `verifyFileIntegrity(fileDest, integrity)` check,
   cheaper because we already hold the expected bytes and can skip
   the re-hash.
3. Match → `Ok(())`. The file is a live CAS entry.
4. Mismatch (or `NotFound` on re-read from a concurrent cleaner) →
   `write_atomic`: open a unique temp path next to the target, write
   `content`, `fs::rename` over the target. Rename is atomic on Unix
   (`rename(2)`) and replaces-in-place on Windows, so observers
   never see a half-written blob. Matches pnpm's `writeFileAtomic` +
   `renameOverwriteSync`.

Temp path scheme mirrors pnpm's `pathTemp`:
`{basename with -suffix stripped}{pid}{counter}`, where counter is a
process-local monotonic `AtomicU64` instead of pnpm's Node.js
`workerThreads.threadId`. Strips `-exec` → appends `x` the same way
pnpm's `removeSuffix` does, so temp files don't look like executable
CAS entries to an observer scanning the shard.

Deliberate divergences from pnpm v11 documented inline:

- No upfront stat. `create_new`/`AlreadyExists` gives us the
  exists-signal for free; stat would be redundant.
- Byte-compare instead of `crypto.hash`. We hold the buffer, so
  equality gives the same correctness guarantee without a second
  full-buffer walk.
- No `locker: Map<string, number>` process-local cache. Pacquet's
  hot path calls `ensure_file` at most once per CAS file per install
  (the `StoreIndex` decides whether we even get here), so the locker
  would be mostly empty work.

Adds three tests covering the new paths — matching-content
short-circuit, mismatched-content atomic rewrite, temp-name scheme
preserves pnpm's `-exec` → `x` suffix transformation.

Port the `EPERM|EACCES|EBUSY` arm of pnpm's `rename-overwrite`
library (zkochan/packages/rename-overwrite/index.js) into the
torn-blob-recovery `rename` call inside `ensure_file`. That arm is
the one retry family that actually hits pacquet in practice:
Windows Defender and other AV / file-indexer tools briefly hold the
destination open when we try to rename our temp file over it, which
fails with `ERROR_ACCESS_DENIED` or `ERROR_SHARING_VIOLATION`. Both
surface through Rust's `io::ErrorKind` as `PermissionDenied` or
`ResourceBusy`, and both clear on their own within tens to hundreds
of milliseconds.

Loop shape matches pnpm exactly: 60-second total budget, start at
zero sleep, grow the per-attempt sleep by 10 ms each iteration,
cap at 100 ms. Any non-transient error kind propagates immediately.

Other retry arms in `rename-overwrite` (`ENOTEMPTY`/`EEXIST`/
`ENOTDIR` swap-rename, `ENOENT` mkdir-and-recurse, `EXDEV` copy-
and-delete) are deliberately **not** ported — see the doc comment
on `rename_with_retry` for the case-by-case reasoning. Short
version: for this specific call site (temp and target in the same
CAS shard dir, both files, no live readers), those arms have no
work to do.

Adds two tests pinning the behavior:

- `transient_rename_error_classifier` rejects any `ErrorKind` other
  than `PermissionDenied` / `ResourceBusy`. A regression that
  classified e.g. `NotFound` as transient would pathologically spin
  for 60 seconds on a legitimately missing source.
- `rename_with_retry_succeeds_fast_when_no_error` pins that the
  happy path returns immediately without sleeping — the first
  attempt's `Ok(())` short-circuits, which matters since the retry
  loop starts with a 10 ms step.

Five review fixes for `ensure_file` hardening:

1. **Streaming byte-compare.** Old `AlreadyExists` branch called
   `fs::read` and did a `Vec<u8>` equality check, doubling peak
   memory for every CAS entry it verified. For a 30 MB tarball entry
   that was 30 MB extra heap per concurrent worker. Replaced with
   `file_equals_bytes` — open, read 8 KB stack-buffer chunks,
   compare each against the corresponding slice of `content`, bail
   on first mismatch. Fixed-size stack buffer regardless of file
   size. Added a length short-circuit (`meta.len() != content.len()`)
   before we open the file at all.

2. **`O_EXCL` on the atomic-write temp path.** Old `write_atomic`
   opened with `create+truncate`, which follows symlinks and
   truncates whatever's there. An attacker (or a stale temp from a
   crashed prior install) pre-seeding the predicted temp path could
   cause us to truncate a file outside the store shard. Switch to
   `create_new(true)`; on `AlreadyExists` advance the pid + counter
   suffix and retry, up to 16 fresh names. Collisions are already
   vanishingly rare given the pid + per-process `AtomicU64` scheme,
   but the retry closes the adversarial / shared-store loophole
   without panicking.

3. **Windows-only rename-retry classifier.** Old
   `is_transient_rename_error` treated `PermissionDenied` and
   `ResourceBusy` as transient on every platform. On Unix, `rename`
   returning those codes is essentially always a permanent
   permission or mount-point issue, so the 60 s retry loop just
   stretches out the failure. Gate the classifier on
   `cfg!(windows)`; non-Windows returns `false` and propagates
   immediately. Doc comment and the classifier test updated to
   reflect the new contract.

4. **Split open / write error classification in `write_atomic`.**
   Previous shape wrapped both in a single `WriteFile` variant,
   making "couldn't create the temp file" and "couldn't write to it"
   indistinguishable. Separate the two call sites: open errors map
   to `CreateFile`, write errors stay as `WriteFile`.

5. **Drop flaky 10 ms timing assertion in
   `rename_with_retry_succeeds_when_no_error`.** On loaded CI /
   slow filesystems a successful first-attempt rename can exceed
   10 ms of scheduling jitter even without the retry path firing.
   Correctness assertions only — the classifier test already pins
   the semantic property we cared about.

Also file handle is now explicitly `drop`ped before `rename` to keep
the sharing-violation window as small as possible on Windows.

Two new tests cover the streaming compare:
- `file_equals_bytes_classifies_match_mismatch_and_length_mismatch`
  pins the exact-match / content-diff / length-diff branches.
- `file_equals_bytes_handles_multi_chunk_files` uses a 20 KB payload
  to exercise the inner `read_exact` loop across multiple chunks
  and plants a last-chunk mismatch to catch "first chunk matched, so
  I returned true" regressions.

The `shard_cache_populates_on_first_write_and_skips_mkdir_thereafter`
test comments still described the pre-review version of `ensure_file`,
which swallowed `AlreadyExists` as `Ok(())` without verifying the
existing bytes. Since b027412 (symlink-safety guard) and 1835847
(streaming byte-compare), the `AlreadyExists` branch routes through
`verify_or_rewrite` and returns `Ok(())` only after byte-matching the
existing file against the buffer; a mismatch takes the
`write_atomic` torn-blob-recovery path instead.

Update the doc block and the inline comment in the test to describe
this actual flow, and point to the cross-crate test that pins the
mismatch branch so a reader can follow the whole contract.