Disable stubTimers in Pro Node renderer for RSC streaming

The renderer's stubTimers default of true replaces setTimeout with a
no-op inside the VM. React's RSC server renderer uses setTimeout
internally for Flight-protocol yielding, so stubbing it makes the RSC
stream open without ever emitting a chunk. The request reaches the
worker, the worker holds the accepted socket, but no data flows.
Fastify eventually closes the idle connection at keepAliveTimeout
(~72s), HTTPX retries once by its retries plugin, and Rails sees
HTTPX::Connection::HTTP2::GoawayError after ~144s.

Non-RSC SSR is unaffected because it doesn't rely on setTimeout for
its async scheduling — only RSC's streaming path hits this.

Verified by running a second renderer alongside on another port with
RENDERER_STUB_TIMERS=false: the stuck path returned a full 9.7KB RSC
payload for ServerComponentsPage in 422ms, vs. the default renderer
timing out on the same request.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: ihabadham

renderer/node-renderer.js

@@ -41,6 +41,12 @@ const config = {
   // deps rely on during SSR. Without URL, react-router-dom's NavLink throws
   // `ReferenceError: URL is not defined` via encodeLocation.
   additionalContext: { URL, AbortController },
+  // RSC requires a real setTimeout. The renderer's default stubTimers:true
+  // replaces setTimeout with a no-op to prevent legacy SSR from leaking
+  // timers, but React's RSC server renderer uses setTimeout internally for
+  // Flight-protocol yielding — with it stubbed, the RSC stream silently
+  // emits zero chunks and hangs until the Fastify idle timeout fires.
+  stubTimers: false,
 };
 
 reactOnRailsProNodeRenderer(config);