Fleet agent: don't let a dropped connection kill the launcher

[rudysev]

What

Loading the phone remote page crashed the launcher. FleetHttpServer ran each connection directly as a pool task:

pool.execute { serve(socket) }

Browsers preconnect speculatively and abandon connections when a tab is backgrounded, so readHead() blocked until the 30s soTimeout and threw SocketTimeoutException. A checked exception escaping a Runnable gets wrapped by ThreadPoolExecutor.runWorker into java.lang.Error, which reaches the thread's uncaught handler:

FATAL EXCEPTION: pool-2-thread-2
java.lang.Error: java.net.SocketTimeoutException: Read timed out
    at com.immortal.launcher.FleetHttpServer.readHead(FleetHttpServer.kt:239)
    at com.immortal.launcher.FleetHttpServer.serve(FleetHttpServer.kt:201)

CrashGuard then recovered the process, so turning on "remote — control from phone" and opening the page from a phone browser bounced the launcher. Every other failure path in the file was already inside runCatching; the header read was the one hole.

Changes

• serveSafely() wraps serve() — timeouts and resets log at debug, anything else warns, and the socket is always closed. A dead connection can no longer take the process down.
• Split the read timeout: 10s while waiting for a request line, 30s once a real request is in flight (uploads keep the long budget). An abandoned connection previously pinned a pool thread for the full 30s.
• Pool 4 → 8: with Connection: close, every asset and poll costs a fresh connection and browsers fan out ~6 in parallel, so the remote page could queue behind itself.

Testing

FleetHttpServerSocketTest drives a real loopback server: reset connections stay off the uncaught handler and the pool keeps serving, plus coverage for preflight, a malformed request, a throwing handler, and stop(). Full suite passes (298 tests).

The unit-test change to app/build.gradle.kts (unitTests.isReturnDefaultValues) is needed because the off-device android.util.Log stub throws "not mocked", which put every logging path out of reach of a JVM test. No test regressions.

Verified on a Portal 10" gen2 (Android 10) with the dev build: held idle connections open past the header timeout, and the same exception now surfaces as

D ImmortalFleet: idle connection timed out: Read timed out

with the PID unchanged and the next request answered normally. The phone remote is usable end to end.

🤖 Generated with Claude Code