fix(auth): refuse on a stuck lock, capture identity at the mkdir seam (#2082)

Copilot review round 6 — five findings (two inline, three suppressed), all
valid.

**A stale lock that cannot be cleared caused unlocked writes.** `acquireLock`
does not only *create* directories: on finding a stale one it removes it and
retries, and that removal can fail — `ENOTEMPTY` for a lock with anything
inside it, `EACCES`/`EROFS` for one we may not touch. Those surface as
ordinary non-`ELOCKED` errors, which the probe read as "locks do not work
here" and degraded on. So every Inspector on the box quietly bypassed the
*same* stuck lock and raced its writes — while the release-failure message
was telling the operator saves would keep failing until they cleared it.

`isStuckOrHeld` now discriminates on **whether the lock directory exists**
rather than on an errno taxonomy: if it is there, something holds it and we
refuse; if it is not, we genuinely could not create one and degrading is the
documented trade (#1848, #1905). Reading the state the decision is about
avoids enumerating error codes per platform — and an enumeration is exactly
what let `ENOTEMPTY` through.

**Identity was captured after the acquire promise settled.** That span
includes the library's own `utimes`/`stat` probe, so a waiter replacing our
directory inside it would have us record *the winner's* identity as our own,
after which the removal guard would accept and delete their lock. It is now
recorded in the `mkdir` callback — the moment the directory becomes ours, and
synchronous with respect to this process, so there is no window.

**The expiry advice was still wrong for `EACCES`/`EPERM`/`EROFS`.** Since the
guard `stat`s before removing, everything reaching the release catch is an
`rmdir` that was refused — and stale takeover reclaims through that same
`rmdir`. The `ENOENT` arm was unreachable for the same reason, so the branch
was dead code: removed, and the advice is now unconditional.

**`proper-lockfile` was missing from `NODE_ONLY_OPTIMIZE_DEPS_EXCLUDE`.** A
fourth externalization surface — the tsup lists configure the production
bundles, not `vite dev`, whose dep scanner would otherwise walk its
CJS/`graceful-fs`/`signal-exit` graph. Added, and `vite-base-config.test.ts`
now asserts it along with `chokidar` and `@napi-rs/keyring`, which were also
absent from that assertion.

**A test was named for something it did not exercise.** "does not treat an
unlistable directory as an empty one" was driving `ENOTDIR`, which is
deliberately treated *as* the fresh-install case, so the actual new behaviour
was untested. Split in two: one for `ENOTDIR`, and a real `EACCES` one using
a `--x` directory — `readdir` denied, a known name still reachable, which is
the asymmetry that makes "unlistable" different from "empty". Driven with a
real mode rather than a stub, since `vi.spyOn` cannot redefine an ESM
namespace export; skipped as root and on Windows, where the mode would not
bite and the test would assert nothing.

Both new tests verified by mutation.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JTHVxSu8AUgHRLvo1ntZ8H
Signed-off-by: cliffhall <cliff@futurescale.com>

clients/web/src/test/integration/auth/node/file-lock.test.ts

@@ -305,6 +305,37 @@ describe("withSecretFileLock degrades rather than failing", () => {
     expect(existsSync(target)).toBe(false);
   }, 90_000);
 
+  it("refuses rather than degrading when a stale lock cannot be cleared", async () => {
+    // `acquireLock` does not only *create* directories — on finding a stale
+    // one it removes it and retries, and that removal can fail. A stale lock
+    // with anything inside it fails `ENOTEMPTY`, which is not `ELOCKED`, and
+    // treating every non-`ELOCKED` error as "locks do not work here" meant
+    // every Inspector on the box quietly bypassed the *same* stuck lock and
+    // raced its writes — while the release-failure message was telling the
+    // operator saves would keep failing until they cleared it.
+    const target = filePath();
+    const lockPath = `${target}.lock`;
+    await fs.mkdir(path.dirname(target), { recursive: true });
+    await fs.mkdir(lockPath);
+    await fs.writeFile(`${lockPath}/stray`, "", "utf-8");
+    // Backdated so it reads as stale — which is what sends `acquireLock` down
+    // the remove-and-retry path rather than straight to `ELOCKED`.
+    const longDead = new Date(Date.now() - 60_000);
+    await fs.utimes(lockPath, longDead, longDead);
+
+    const store = new FileSecretStore({ filePath: target });
+    const err = await store
+      .set("srv", "env:MINE", "1")
+      .catch((e: unknown) => e);
+
+    expect(err).toBeInstanceOf(SecretStoreUnavailableError);
+    expect((err as Error).message).toMatch(/was not saved/);
+    // Nothing written behind the stuck lock, and no "unprotected" warning:
+    // this is a refusal, not a degrade.
+    expect(existsSync(target)).toBe(false);
+    expect(warnings()).not.toContain("not protected");
+  }, 90_000);
+
   it("takes over the lock of a holder that died, rather than failing the save", async () => {
     // The invariant behind refusing on `ELOCKED`: refusing is only defensible
     // because a *crashed* holder resolves on its own first. `RETRY` therefore