[AdaAibaby]

Rebased follow-up to #3416, which @ryan-sana closed with an invitation to "rebase the one-line change onto current main." The ReadTimeout code is still present on main (packages/api/main.go:254), so the problem in #3415 is unaddressed.

Summary

• Remove ReadTimeout: maxReadTimeout (10s) from the http.Server.
• Remove the now-unused maxReadTimeout constant.
• Keep ReadHeaderTimeout: 5s (slowloris protection) and WriteTimeout: 75s unchanged.

Net diff: 2 deletions.

Why

ReadTimeout is measured from TCP accept, so it includes the time the serve goroutine spends queued in the Go scheduler before it runs. Under high concurrency that queue time alone can exceed 10s, so the deadline fires before io.ReadAll ever executes — surfacing as i/o timeout body-read errors that look like client disconnects or auth failures.

The intended per-request ceiling is the RequestTimeout middleware (cfg.RequestTimeout, a context deadline — still wired at main.go:173), which ReadTimeout preempts and so is never reached in practice.

Once headers have arrived (guarded by ReadHeaderTimeout), there's no meaningful slow-body attack surface: request bodies on this API are small JSON payloads sent in a single TCP segment. WriteTimeout (asserted > cfg.RequestTimeout at compile time) still bounds the response side.

Verification on current main

• ReadTimeout/maxReadTimeout confirmed still present and used only at the server construction site (no other references).
• RequestTimeout middleware, ReadHeaderTimeout, and the WriteTimeout compile-time assertion all still in place — so the diagnosis holds unchanged.
• go build ./packages/api/... and go vet pass.

Test plan

• Staging: replay ≥100 simultaneous sandbox creates; confirm i/o timeout body-read errors disappear.
• /health still responds under load.
• Slowloris still rejected within 5s (ReadHeaderTimeout): a client that opens a connection but never sends headers is dropped.

Closes #3415. Supersedes #3416.