perf: reactor (kqueue/epoll) to scale past thread-per-connection

Problem

nitro_server does not gain throughput from more isolates on /hello, while dart:io scales linearly:

nitro leads at 1 isolate (~1.8×) but ties/trails once dart:io uses shared: true across 4 isolates.

Measured root cause

A standalone experiment (N independent ServerInstances on one port, C++ raw client, respond inlined on the worker — no Dart) shows the engine's ceiling on an M1 Pro (8 cores):

So one engine already saturates the box at ~108k and adding engines does not scale — SO_REUSEPORT-per-isolate is ruled out as a fix. The gap between 108k (engine) and 58k (real nitro) is the async Dart round-trip plus thread-per-connection: ~64 worker threads park in poll() on 8 cores. sample profiles are poll-dominated. More connections do not help (they add threads, raising latency).

Proposal

Replace thread-per-connection with an event-driven reactor: one kqueue/epoll thread per isolate watches all connection fds; a small worker pool (≈ core count) handles ready fds and returns them, instead of one parked thread per connection. This decouples connections from threads and should approach the ~108k engine ceiling, also lifting the "hundreds not thousands of connections" limit.

A Poller scaffold exists in commit 2df34f3. Large change; must preserve the direct-write answer path, WebSocket, streaming, sendfile, TLS, and drain semantics, all currently covered by the C++ and Dart suites.

Start with the Poller scaffold in commit 2df34f3 and inspect the existing thread-per-connection path and poll-dominated profiles. Run the existing C++ and Dart suites before changing the reactor. Done means the direct-write answer path, WebSocket, streaming, sendfile, TLS, and drain semantics remain covered while connection handling scales beyond the current thread limit.