ReviewOS's production web service is being killed at its unchanged 2 GiB memory limit while roughly 175 web connections overlap. A 30-second JSC profile places the work in STX page rendering (directives, loops, interpolation, components and CSS); active render contexts accumulate while slow queries await. The Git proxy shares this web process, so a web OOM also truncates checkouts used by HQ's macOS acceptance jobs.
Bound concurrent page rendering and its waiting queue in the framework, before creating template contexts. Respect queued request cancellation and waiting deadlines, always release slots after failures, and return an uncached 503 with Retry-After when full. Existing API hooks, Git proxy traffic and static assets should remain outside the render admission gate. Queued requests must retain their own cookies and parameters.
Acceptance: actual HTTP regression covering static and dynamic renders, capacity refusal, cancellation/timeout, error recovery and request isolation; normal published package consumption; production memory and normal clone verification. This is a render capacity safeguard; the separately identified highlighted-code retention fix does not establish that all memory growth is resolved.
Related: https://github.com/ReviewOS/reviewos.org/issues/8 Related: https://github.com/stacksjs/hq.training/issues/346 Related: https://github.com/stacksjs/hq.training/issues/366 Related: https://github.com/stacksjs/hq.training/issues/368