Wake native runtime for queued WebSocket events #284

Parent investigation: #280
Product acceptance: #252

Problem

The native WebSocket transport appends open/message/close events from its network thread without waking the owning runtime worker. If no host evaluation or other producer arrives, ready socket events wait for the worker's 16 ms watchdog. A self-refilling Worker or MessagePort source can also repeatedly win fixed-priority task arbitration ahead of a ready socket event.

A direct no-poll echo oracle reproduces the contract failure: after starting 100 sequential connect/echo/close cycles, the unchanged runtime does not complete within 500 ms unless the observer repeatedly evaluates JavaScript and wakes the worker. This is a generic WebSocket/runtime scheduling defect. It is one dependency of #280, but correcting it alone does not satisfy #280's unchanged Code OSS 2 s product gate.

Acceptance

• Empty-to-nonempty WebSocket event queue transitions wake the runtime worker without evaluator polling.
• Worker, MessagePort, and WebSocket task sources make bounded progress under a self-refilling competing queue.
• 100 cold/warm echo cycles retain bounded p95 latency and competing-task count.
• Text, binary, FileReader, close, cancellation, and reconnect behavior settle exactly once.
• Queue and wake telemetry prove signalled progress; teardown leaves no timeout-dependent socket work.
• Repeated lifecycle checks bound V8 heap and process RSS.
• Directly related worker, postMessage, and idle-platform checks pass on macOS and Linux.

Retained baseline

With observer polling removed, the unchanged runtime fails before 500 ms with browser WebSocket API did not complete text/binary/close echo lifecycle. The candidate completes all 100 cycles before the single observation, with cold 0.118 ms, warm p95 0.155 ms, at most 23 competing MessagePort deliveries, and stable 1,027,564-byte V8 heap.