api: ReadTimeout: 10s kills body reads under high concurrency, conflicting with requestTimeout: 70s

Problem

Under high concurrency (e.g. 1 000 simultaneous sandbox creates) the API returns a flood of errors with:

reading failed: read tcp 192.168.0.146:3000->...: i/o timeout

Root cause

packages/api/main.go configures two competing timeouts:

Go's http.Server.ReadTimeout starts counting from the moment the TCP connection is accepted — including scheduler queue time. Under high concurrency, goroutines may wait >10 s in the scheduler before they ever execute and call io.ReadAll. By then the ReadTimeout has already fired and the connection is dead.

requestTimeout: 70 s is the intended per-request ceiling but is never reached in practice because ReadTimeout: 10s fires first.

Why ReadHeaderTimeout is sufficient

ReadHeaderTimeout: 5s already guards against slowloris (headers never arrive). Once headers are received and ServeHTTP starts, request bodies on this API are small JSON payloads (<1 KB) sent in a single TCP segment — there is no meaningful slow-body attack surface. The requestTimeout: 70s middleware context provides the actual per-request deadline for handler execution.

Fix

Remove ReadTimeout from the http.Server config. Keep ReadHeaderTimeout for slowloris protection.

Start in packages/api/main.go and inspect the http.Server timeout configuration, especially ReadTimeout, ReadHeaderTimeout, and the requestTimeout middleware described in the issue. Done means removing ReadTimeout while retaining ReadHeaderTimeout and the 70-second request deadline, then verifying the API builds and its existing tests pass.