test(wasix): skip the cluster shared-dgram known_issues test

[Arshia001]

Stacked on #143. Merge that first.

What fails

known_issues/test-dgram-bind-shared-ports-after-port-0 times out on both WASIX lanes, on this branch and on main (run 31362885750, job 93375162660) — it is not caused by #143.

=== release test-dgram-bind-shared-ports-after-port-0 [negative] ===
--- TIMEOUT ---

Why

Cluster shares a dgram socket by sending the bound descriptor to the worker over IPC, and primary.js always selects SharedHandle for udp4/udp6 regardless of scheduling policy:

if (schedulingPolicy !== SCHED_RR ||
    message.addressType === 'udp4' ||
    message.addressType === 'udp6') {
  handle = new SharedHandle(key, address, message);   // send(errno, null, this.handle)

WASI has no msghdr/SCM_RIGHTS, so that descriptor can never be delivered. Instrumenting the path shows exactly where it stops:

W: up
P: worker online                                   <- IPC itself is fine
W: calling bind(exclusive:false) -> cluster queryServer
W: 15s elapsed, bind cb never fired                <- reply never arrives
P: TIMEOUT (still waiting)

The worker's bind callback never fires, so it never sends {message:'success'}, so the primary's worker1.on('message', common.mustCall(...)) never fires and the run hangs until the harness kills it.

A timeout fails a [negative] test regardless of which way it would have resolved — an expected-to-fail test still has to fail promptly. And it can never reach its intended outcome on WASIX, which requires a genuinely shared UDP socket.

Why a skip

The whole cluster/fork family is already a documented WASIX environment limit. Its non-negative sibling sequential/test-dgram-bind-shared-ports.js has been in WASIX_SKIP_CLUSTER_FORK_TESTS since the original triage. This one escaped only because the list carried no known_issues/ paths — every other entry is a parallel/ or sequential/ path.

On the underlying bug

While tracking this down I found a real defect and fixed it separately in wasix-org/libuv#14: a handle-passing IPC write reported success while silently dropping the message, because libuv's ENOSYS was raised inside the queued write and Node's channel discards that status (req.oncomplete = () => callback(null)). That PR rejects up front so uv_write2() fails synchronously.

It is what made this diagnosable — the primary now reports ENOSYS instead of stalling mutely — but it does not make this test pass, and this PR does not depend on it. The submodule pin is unchanged.

Verification

Built against the pinned libuv (deps/libuv-wasix 71cdbb57, i.e. what CI builds):

	before	after
node:dgram	60 passed / 1 failed	60 passed / 0 failed

[00:17|% 100|+  60|-   0]: Done
All tests passed.

One caveat worth stating: this is the quickjs-wasix build locally. The failure and its cause are identical on both lanes (same TIMEOUT, same engine-independent IPC path), so CI is the check for v8-wasix.