[AdaAibaby]

Problem

fix #3563.
PR #3810 capped the /init request body at 1 MiB to stop a guest process from OOM-killing envd via an unbounded io.ReadAll before auth. That fix is correct but narrow:

• it patches one endpoint, not the class of problem;
• it does nothing about the slowloris surface left by ReadTimeout: 0;
• it gives no way to tell whether envd is actually being OOM-killed in the fleet — the real question behind bug(envd): PostInit reads request body with io.ReadAll and no size limit, enabling OOM via oversized payload #3563.

This replaces the single-endpoint fix with layered defense.

Layers

Layer 1 — server edge (envd/main.go)
Add ReadHeaderTimeout (10s) and MaxHeaderBytes (1 MiB). ReadHeaderTimeout bounds only the header read, so it closes the slowloris surface without cutting the long-lived body / connect streams that require ReadTimeout to stay 0. gosec G112 also flagged the previously-unset value. Zero behaviour change for legitimate traffic.

Layer 2 — per-path body cap (envd/internal/api/bodylimit/)
New middleware caps every path at 1 MiB by default and exempts the streaming endpoints (/files, /upgrade) and the connect services (/filesystem.*, /process.*), which stream to disk or carry their own framing. Default-deny: a handler added later is capped without the author remembering to. The connect services additionally get connect.WithReadMaxBytes. PostInit keeps the 413 MaxBytesError branch but no longer caps inline — the cap is applied at the edge, below auth.

Layer 3 — observability (orchestrator/pkg/metrics/sandboxes.go)
The OOM kills envd already reports off /dev/kmsg were only logged, never counted or classified. Add orchestrator.sandbox.oom.kills split by victim_class:

• control_plane = envd itself was killed — the event bug(envd): PostInit reads request body with io.ReadAll and no size limit, enabling OOM via oversized payload #3563 is about; should stay 0.
• workload = a user process hit its cgroup memory.max — an expected capacity event.

Plus orchestrator.sandbox.oom.kills_dropped as a floor for kills past envd's 32-entry window. envd kills now log at Error so they alert on their own. This lets sum by (victim_class) answer how much of the fleet's OOM is actually the control plane vs. workload capacity.

Deliberately out of scope

This does not flip the build-envd-memory-protection feature flag (memory.min on envd.service), which is the primary root-cause protection (it stops the kernel reclaiming/killing envd under pressure, covering every allocation path a body cap cannot). It is left to a separate rollout because it rebuilds templates and enters the base-layer cache key. Recommend landing Layer 3 first, reading victim_class, and deciding memory.min rollout from the data.

Testing

• go build / go vet / gofumpt -l clean across envd, orchestrator/pkg/metrics, shared/pkg/telemetry.
• New tests pass: bodylimit (over-cap → 413, at-cap → 200, exempt paths uncapped, exempt() table) and oomVictimClass.
• Existing internal/api suite (incl. init) passes.

Refs #3563. Supersedes #3810, #3564.

/cc @ryan-sana