[bartlomieju]

The node-compat PipeWrap handle is the native backing for node:net
unix-domain sockets, and is also reachable directly from user code via
process.binding("pipe_wrap").Pipe. Several of its operations mutated the
filesystem without going through Deno's permission model.

Binding a unix-domain socket creates a socket inode on disk via
socket(2) + bind(2), yet bind() performed no permission check. Worse,
uv_pipe_bind recorded the bound path on the handle before attempting the
bind and did not clear it on failure, so a failed bind against an existing
file still armed the two operations that act on the recorded path: fchmod()
(which calls chmod(2)) and the unlink-on-close in close_pipe (which calls
remove_file). The net effect was that code granted no --allow-* flags could
create a socket inode at an arbitrary writable path, change the mode of an
existing owned file, or delete an arbitrary unlinkable file.

This moves the filesystem permission check to bind(), where the inode is
actually created, mirroring connect() and Deno.listen({ transport: "unix" }).
A denied bind throws NotCapable and never records the path, so the fchmod
and unlink-on-close paths can no longer reach an arbitrary file. As defense in
depth (and to match libuv, which stores the path on the handle only on success),
uv_pipe_bind now records the bound path only after bind(2) succeeds.

The existing permission check in listen() is left in place. A new spec test
under tests/specs/permission/node_pipe_wrap_no_perms runs with no permissions
and asserts that bind() is denied and that no path is left armed for fchmod.
Legitimate unix-socket servers created with --allow-read --allow-write
continue to work, and the existing pipe_open_fd and http_address_override
unix-socket suites pass unchanged.