fix(config,std): make the -1 'no timeout' sentinel idempotent and map it onto net/http's own encoding

[FumingPower3925]

Fixes #594 (found while measuring #584). The rig that found the defect judges the fix, the negative control was run, and an adversarial reviewer re-read the pushed diff rather than the report.

Reviewer verdict

Finding closed: True. Mergeable: True.

I read the pushed diff (origin/fix/594-timeout-sentinel, 6188b4b + af5a280, 7 files, 2 production files) rather than trusting the report, and re-ran the controls myself in a throwaway git archive copy (nothing in the repo touched).

FINDING 1 — celeris's "disabled" encoding (0) does not mean disabled to net/http on ReadHeaderTimeout/IdleTimeout. CLOSED. engine/std/engine.go now routes all four http.Server fields through stdTimeout(d) (d <= 0 -> -1). I verified the semantics claim against the actual toolchain source rather than the comment: /opt/homebrew/Cellar/go/1.27.0/libexec/src/net/http/server.go:1039 and :1042 guard ReadTimeout/WriteTimeout with d > 0, and :3745-3756 are the two fallbacks (if s.IdleTimeout != 0 { return s.IdleTimeout }; return s.ReadTimeout, same shape for ReadHeaderTimeout). So the documented mapping is exact, and -1 is safe on all four because every consumption site is a > 0 guard. The only other reader of these fields is tlsHandshakeTimeout (server.go:969, "minimum of any POSITIVE"), which skips <= 0 exactly as it skipped 0 before — and engine/std never serves TLS (no TLSConfig/ServeTLS anywhere in the package; configureHTTP2/h2IdleTimeout is unreachable because shouldConfigureHTTP2ForServe needs a TLSConfig, and the h2c path uses its own http2.Server). No behaviour change outside the intended one.

FINDING 2 — the table test used one value for all four fields and asserted only the celeris encoding. CLOSED. engine/std/timeout_sentinel_test.go is now per-field, includes the two mixed cases ({0,-1,0,-1} and {3s,-1,3s,-1}: header+idle disabled while ReadTimeout stays enabled — the only shape that exposes the fallback), runs each case both raw and via-doPrepare, and asserts three things per field: e.cfg.X, the raw http.Server.X (must be strictly negative when disabled), and netHTTPEffective (net/http's own resolution, transcribed from the source lines above). Plus two real-socket tests.

RE-VERIFICATION NUMBERS — reproduced, not taken on faith:

• Branch as pushed: go test ./resource/ ./engine/std/ both ok; the wire tests log explicit-header-timeout-kills served=false firstResultAfter=302ms response="HTTP/1.1 400 Bad Request" and sentinel-disables served=true firstResultAfter=10.894s (i.e. it outlived the 10s default), idle test serves a 200 after 1.2s idle with ReadTimeout=300ms.
• Negative control A (resource/config.go reverted to origin/main, std fix kept): exactly the three /via-doPrepare subtests fail (all-disabled, mixed-with-default-read, mixed-with-explicit-read) and the header wire test dies at 10.002s — matches the report's 10.001s.
• Negative control B (engine/std/engine.go reverted to origin/main, config fix kept): exactly six table subtests fail (the same three cases × raw and via-doPrepare) and the header wire test dies at 302ms with a 400 — matches the report's "six subtests / 301ms". The report under-claims here: TestIdleTimeoutSentinelOnTheWire also fails under control B (second request after idle: read: EOF), so the idle half has its own negative control too.
  Both controls therefore isolate the two halves of the bug independently, which is the property that was missing before.

NOTHING NEW BROKEN, checked specifically:

• Hot path: resolveTimeout and stdTimeout run only in WithDefaults and the std constructor. unsafe.Sizeof(resource.Config{}) is 216 bytes on both main and the branch — the new unexported defaulted bool lands in existing padding, so the per-worker/per-loop Config copies cost nothing.
• Invariants in nearby code: every celeris consumer of these fields is a > 0 guard (engine/iouring/worker.go:1034, :1357, :4356-4362; engine/epoll/loop.go:297, :649, :2365, :2473-2479) or an == 0 no-op (internal/conn/h1.go:64), so propagating a real 0 is what those comments already promise. I hand-checked the two linux assertions I cannot run: with emptyIters=200/listenFD=3 adaptiveTimeout really returns 100ms idle / 50ms detached with the header timeout off and 25ms/25ms with it on, and epoll's adaptiveTimeoutMs(100) with consecutiveEmpty=200 really returns 400/50 vs 25/25 — the test expectations match the source.
• The defaulted marker cannot leak a stale "already normalised" into a fresh config: Config.toResourceConfig (config.go:247) builds a literal every time, it is the only resource.Config literal in non-test code, and doPrepare's configureFn only sets Listener. Config has func fields so nothing compares it with ==, and there is no reflect.DeepEqual on it anywhere.
• MaxRequestBodySize was folded into the same idempotency (0 = unlimited downstream: internal/conn/h1.go:350, h2.go/processor.go:185, engine/std/bridge.go:51) and is covered by its own table test.
• No committed scratch files, no debug prints, no CHANGELOG/doc churn: the diff is 2 production files + 5 test files. go vet clean on darwin, and GOOS=linux CGO_ENABLED=0 go vet ./engine/epoll/ ./engine/iouring/ ./adaptive/ is clean, so the three linux test files compile and have no duplicate symbols. Full go test ., ./resource/, ./engine/std/ all pass.

Residuals the reviewer recorded

Nothing blocking. Three residuals, all minor:

1. Self-contradicting doc comment the commit touched but did not clean. resource/config.go:46 still says of ReadHeaderTimeout "Zero falls back to ReadTimeout." — that is net/http's rule, never celeris's — while the line the commit appended at the bottom of the same block says "0 asks for the default (10s); -1 disables it (0 after WithDefaults)." The stale sentence predates this branch, but it now sits nine lines above its own contradiction inside a comment this commit edited. One-line deletion.

2. Validate() asymmetry (pre-existing, not a regression). resource/config.go:132-139 bounds ReadTimeout/WriteTimeout/IdleTimeout at >= -1 but has no such check for ReadHeaderTimeout, so ReadHeaderTimeout=-5 is silently accepted as "disabled" while ReadTimeout=-5 is an error. Unchanged by this branch (both before and after, WithDefaults collapses any negative before Validate ever sees it, so even the three checks that exist are dead for engine-constructed configs — only doPrepare's pre-normalised path can trip them).

3. Small public-API semantics change worth a release note: resource is an exported package, so an external caller who does cfg := resource.Config{...}.WithDefaults() and then sets cfg.ReadTimeout = 0 before handing it to an engine constructor now gets "disabled" where they previously got the 60s default. That is the deliberate point of the defaulted marker and is documented on the field, but it is a behaviour change beyond the four timeouts named in Config timeouts: the documented -1 'no timeout' sentinel is normalised twice and becomes the 10 s default (ReadHeaderTimeout, ReadTimeout, WriteTimeout) #594 (MaxRequestBodySize moves the same way: a double-normalised unlimited now stays unlimited instead of snapping back to 100 MB).

Also note the linux-only tests (epoll, iouring, adaptive) were type-checked here by cross-GOOS vet but not executed — they need the cluster.

[FumingPower3925]

The failing check is celeris#610, not this change. TestTokenRefill asserts a 429 on the second request of a limiter running at 1000 RPS with burst 1, which requires both requests to land inside one millisecond; under -race on a shared runner a token refills first and the request is allowed. This branch touches only the timeout-sentinel path in resource, the three engines and adaptive, nothing within reach of the rate limiter. Re-running.

[FumingPower3925]

Third unrelated CI failure on this branch, third time it is not this change. TestMetricsDuringListenIsRaceFree failed with the reader never ran, which is the test racing itself: nothing orders its reader goroutine's first call against the main goroutine setting stop. Fix in #613, with the honest caveat that I could not reproduce it locally in 84 attempts.

Running tally for this branch, which touches only resource/config.go, engine/std and three timeout-sentinel test files: celeris#610 (TestTokenRefill racing the wall clock), celeris#607 (a close handshake that never completes, on epoll this time), and now #613. Re-running.