writer-lock test assumes a live PID 1, so #1744 cannot pass on Windows

[bompus]

__tests__/writer-lock.test.ts > writer lock (#1740) > reports taken when a live foreign pid holds the lock fails on Windows, on a clean checkout of main, with no local changes.

AssertionError: expected 'acquired' to be 'taken'
  __tests__/writer-lock.test.ts:65
    const r = tryAcquireWriterLock(root, 'direct');
    expect(r.kind).toBe('taken');

Cause

The test writes pid: 1 into writer.pid to stand in for a live foreign holder, and its own comment says why: "On Linux, PID 1 is almost always alive."

Windows has no PID 1. tryAcquireWriterLock therefore reads the lock as stale, clears it and acquires — which is the correct behaviour for a dead holder. The test is asserting a POSIX-only property of the fixture, not a property of the lock.

Reproduction

Windows 11, Node 26.8.1, vitest run __tests__/writer-lock.test.ts:

× writer lock (#1740) > reports taken when a live foreign pid holds the lock
  Tests  1 failed | 3 passed (4)

Verified on origin/main at both edcd36e and bb204f8, in a worktree containing nothing else, so it is not an interaction with anything downstream.

Suggested fix

Either gate it — it.runIf(process.platform !== 'win32') — or make the holder genuinely live on every platform by spawning a child and using its pid, which also tightens the test on Linux (PID 1 is an assumption there too, just a safe one).

I'd lean toward the spawned child: it tests what the lock actually promises, that a live holder is not stolen from, rather than that a specific number happens to name a running process.

Why it matters downstream

Reported because it is currently a hard blocker rather than cosmetic noise: a downstream promotion pipeline gates on a zero-failure suite, so this one test stops a Windows host from promoting any build of main at all. Happy to send either fix as a PR if you have a preference.