peer-link: closing a displaced server unlinks the winner's socket

The bug is in vscode-ext/src/peer-link.ts, specifically the closeServer function. Start by reading the linked libuv source to understand uv__pipe_close's behavior. Reproduce the race condition with Node 26.9 as described. The fix likely involves creating a unique socket path and using link() atomically, so study Node's fs module for atomic operations. Check docs/specs/vscode.md for the brokerConfirmed logic to understand the broader context.

closeServer in vscode-ext/src/peer-link.ts documents "Unlink only when the path still names our socket", but unlink only gates the explicit rm. closing.close() unlinks the path on its own: libuv's uv__pipe_close unlinks pipe_fname unconditionally. Reproduced on Node 26.9: A binds, B unlinks and rebinds, A.close() removes B's socket.

So the reclaim stand-down (closeServer(false)) removes the winner's socket too, not only disposal. Trace (from the #753 review):

1. A and B both clear the corpse; B displaces A. Both are inside stillOurs, and A's 250 ms expires first.
2. A mismatches and stands down: A.close() unlinks the path, which now names B's socket.
3. If B's stat landed before that unlink, B confirms and serves an unreachable socket. A's next round tryBinds the free path uncontested and confirms immediately. That leaves two confirmed brokers, which brokerConfirmed exists to prevent (docs/specs/vscode.md → "A bind is not a role until it is believed").

A likely fix direction is an atomic create-only publish: bind a unique path, then link() it onto the fixed one, which fails EEXIST instead of displacing. The unique path is then the one libuv unlinks on close.

Surfaced in #753, which narrows a different race and doesn't address this.