Browser client stops reconnecting after a single HTTP 503 handshake

Affected: unmodified npm RivetKit 2.3.13 and 2.3.17 (latest checked 2026-09-11), Chromium 153.0.8010.12, Bun 1.4.0.

Standalone reproduction. After cloning:

bun install --frozen-lockfile --ignore-scripts
bun run browser:install
bun run repro

A loopback test gateway uses real browser WebSockets and a minimal Rivet Init frame:

1. Establish an SDK connection, then terminate its socket.
2. Return HTTP 503 once on its next handshake; accept all subsequent handshakes.
3. The original client emits client/connection_open_failed, becomes idle, and makes no further attempts during a five-second observation window.
4. A fresh SDK client connects to the same endpoint and actor key while the original remains idle.

Expected: The original connection resumes reconnecting after transient gateway unavailability.

Actual: Recovery stops after the failed handshake. Healthy reconnect succeeds; a persistent HTTP 401 control also becomes idle after one attempt. All six cases are asserted across both versions; exit 0 confirms reproduction.

Browsers expose both 503 and 401 handshake failures as close code 1006, so indiscriminate retries can also retry permanent authentication failures.

Start with the standalone reproduction and run its bun install, browser:install, and repro commands to observe the browser WebSocket client after the HTTP 503 handshake failure. Trace the client path that emits client/connection_open_failed and becomes idle; done when transient 503 failures resume reconnecting without retrying persistent 401 failures.