[crazyads69]

Summary

Two uwz(kqueue) patches that remove a load-induced invalid state and a
queue corruption on the kqueue backend (macOS, BSD). Base: uwz/zig-0.16
at cbf01bc432a84cd91a99c1cb1031b46416d044c7.

Ledger	Commit	Upstream reference
XEV-003	keep a rearmed completion active after submit reported it	mitchellh#245 (open, unmerged; author preserved). Reference only: nothing is sent upstream.
XEV-004	queue a still-readable completion once	None (downstream). Related reports: mitchellh#169 and mitchellh#122.

Why

Downstream symptoms on macOS with the 2.1.5 server:

• error(libxev_kqueue): invalid state in submission queue state=.active
  with op=accept at 64 concurrent connections.
• queue.zig:24 assert(v.next == null) panic in
  cluster: programmatic shutdown drains the signal watcher
  (also at the current pin).

Mechanism for XEV-004, from tracing every completion push and every kevent
return in submit(): a level-triggered filter is reported again by each
kevent call until its callback drains it. A completion already waiting in
the completion queue was queued again, so perform() ran twice. A second
read or accept consumed data or a connection and then overwrote the result.

Evidence

Server start, one wrk -t2 -c64 -d2s burst per start, ReleaseSafe,
trial counted only if the server logged server listening and wrk completed
more than 1000 requests:

Libxev	Valid trials	Trials with the invalid-state log
pin cbf01bc	28	12
with these two commits	29	0

Full downstream suite (645 tests): 633 passed, 10 skipped, 2 failed with the
patches. The 2 failures (config: default slab carries the router region at the end, kernel: validate_umem accepts page-aligned power-of-two regions)
also fail at the current pin and are unrelated.

Alternating A/B throughput, ReleaseFast, 64 connections, loaded host:
control 23.0-23.8k req/s, patched 24.4-24.9k req/s.

Fork tests: zig build test 61/61 on macOS. The new test
kqueue: a still-readable completion is queued once across submits fails
without the guard (expected 2, found 1: a byte is lost) and passes with it.
zig build also succeeds for x86_64-macos, x86_64-linux, and x86_64-windows.

PR 224 (mitchellh/libxev) was evaluated and rejected: with it the
invalid-state log still appeared in 12 of 30 starts and a downstream timer
test hung. PR 170 only clears next before re-enqueueing, which would hide the
double queue.

Review and merge checklist (docs/dependency_forks.md)

• Build/vendor and transport/runtime review of the kqueue.zig range
• Add ledger rows XEV-003 and XEV-004 in uWebZockets docs/dependency_forks.md
• Merge into uwz/zig-0.16 (no force-push, no rewrite)
• Pin the resulting full 40-hex commit in the four zon views with the
  Zig package hash and Nix hash, in a separate uWebZockets change
• Re-run scripts/check_libxev_fork.sh

Follow-up hardening (XEV-005)

The first review found three dispatch gaps that are now included in
86d628ac326d69a097ac42c527b04f3389d20d68:

• guard both dispatch loops against a completion currently being called back
  and against a completion queued by a nested submit();
• flush staged EV_DELETE changes before a no_wait tick returns;
• balance EV_ERROR and non-kqueue .rearm active counts.

Queued-result cancellation remains ordered after the callback because replacing
an already-consumed accept or read result can lose a socket or data. That
pre-existing limitation is documented in stop_completion.

Ledger: XEV-005. Regression tests are in src/backend/kqueue.zig.
Exact head 86d628ac326d69a097ac42c527b04f3389d20d68 passes
65/65 tests on macOS arm64 in both Debug and ReleaseSafe, and 142/146 on
Linux (4 skipped).

[Coder-Blue]

Approved for XEV-003, XEV-004, and the XEV-005 dispatch hardening. Exact head 86d628a passes 65/65 kqueue tests on macOS arm64 in Debug and ReleaseSafe, 142/146 on Linux (4 skipped), across the macOS/FreeBSD/Windows cross-builds, and with the downstream tree at 647/647 on Linux. Merge with a merge commit so the ledger commits remain distinct.