TS: pump in-process FFI inbound frames promptly (fix macOS RPC hangs)

The in-process FFI host has no libuv handle of its own, so koffi delivers inbound
(server→client) frames only when the event loop turns. The keep-alive timer used
a 60s interval, which kept the loop from exiting but let it park between ticks.
When the SDK issues a bare request and only awaits the response — e.g. the
sequential `session.rpc.permissions.*` calls — there is no other loop activity,
so on macOS the inbound response frame sat undelivered until the next tick and
the round-trip stalled past the test timeout. Streaming turns kept the loop busy
and so were unaffected, which is why only a handful of RPC-only tests hung and
only on macOS.

Shorten the pump interval so inbound frames are serviced within a few
milliseconds. The empty callback is cheap and only runs while a connection is
open. This is the koffi analogue of the .NET host's thread-safe Channel
callback, which wakes its reader immediately regardless of loop state.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Author: SteveSandersonMS

nodejs/src/ffiRuntimeHost.ts

@@ -125,13 +125,25 @@ export class FfiRuntimeHost {
     private disposed = false;
     private outboundCallback: KoffiRegisteredCallback | undefined;
     /**
-     * Keeps the libuv event loop alive while the FFI connection is open. Unlike the
-     * stdio/TCP transports (whose pipe/socket handles keep the loop alive), the FFI
-     * transport has no libuv handle of its own, and native→JS callbacks are delivered
-     * via the event loop. Without a live handle the loop can park with no work and the
-     * queued callback delivery races into a crash.
+     * Keeps the libuv event loop alive AND turning while the FFI connection is open.
+     * Unlike the stdio/TCP transports (whose pipe/socket handles keep the loop alive),
+     * the FFI transport has no libuv handle of its own, and native→JS callbacks
+     * (inbound server→client frames) are delivered via the event loop. Without a live
+     * handle the loop can park with no work, and koffi's cross-thread callback delivery
+     * is only serviced when the loop next turns.
+     *
+     * The interval is deliberately short: when the SDK issues a bare request and then
+     * only `await`s the response (e.g. `session.rpc.permissions.*`), there is no other
+     * loop activity, so a coarse interval let the loop sleep and the inbound response
+     * frame sat undelivered until the next tick — on macOS this stalled such round-trips
+     * past the test timeout (streaming turns kept the loop busy and so were unaffected).
+     * A few-millisecond tick keeps inbound delivery prompt; the empty callback is cheap
+     * and only runs while a connection is open. This is the koffi analogue of the .NET
+     * host's thread-safe `Channel` callback, which wakes its reader immediately.
      */
     private keepAlive: ReturnType<typeof setInterval> | null = null;
+    /** Interval (ms) for {@link keepAlive}; short so inbound frames are pumped promptly. */
+    private static readonly INBOUND_PUMP_INTERVAL_MS = 4;
 
     /** The stream JSON-RPC reads server→client frames from. */
     readonly receiveStream: PassThrough;
@@ -249,7 +261,7 @@ export class FfiRuntimeHost {
             throw new Error("copilot_runtime_connection_open failed.");
         }
 
-        this.keepAlive = setInterval(() => {}, 60_000);
+        this.keepAlive = setInterval(() => {}, FfiRuntimeHost.INBOUND_PUMP_INTERVAL_MS);
     }
 
     private writeFrame(frame: Buffer): void {