findListener/waitForListener returns null for a live loopback listener

[NathanFlurry]

Summary

NodeRuntime.findListener({ port }) returns null and NodeRuntime.waitForListener({ port }) times out even when a guest server is demonstrably listening on that port — proven because NodeRuntime.fetch(port, ...) (host→guest vmFetch) reaches the same port and returns 200 in the same run.

Repro

1. spawn (or exec) a guest that binds an http server on 127.0.0.1:3000.
2. await runtime.fetch(3000, { path: "/health" }) → 200 (server is up).
3. runtime.findListener({ port: 3000 }) → null.
4. await runtime.waitForListener({ port: 3000 }) → polls the full timeout and rejects.

Root cause

packages/core/src/kernel-proxy.ts:1286 — findListener is synchronous but populates its result from an async refreshSocketLookup cache that starts null. NodeRuntime.waitForListener's poll loop reads the synchronous return, so it can keep observing the stale null. The socket-table lookup is not surfacing the loopback (127.0.0.1) listener that vmFetch can reach.

Fix direction

Either make the lookup awaited (so waitForListener polls the freshly-refreshed cache) or correct the listener match so loopback listeners are surfaced. This pair should not be relied on until fixed; vmFetch works regardless.

Context

Introduced while exposing wire-protocol capabilities on the NodeRuntime TS API. vmFetch, spawn, host tools, and AbortSignal cancellation from the same batch verified working end-to-end.