fix(chart): cap per-pod backend concurrency at the frontproxy (maxconn)

[ServerSideHannes]

What

Cap per-pod backend concurrency at the frontproxy (haproxy maxconn) to stop the concurrent-backup OOM that lives below the app's memory limiter.

Why the app limiter can't fix this

uvicorn buffers each in-flight request body off the socket before our memory limiter runs. Under a backup flood, request bodies pile up in the HTTP server's C-level buffers — the governor reads ~64MB while RSS hits 512Mi+ and the pod is OOMKilled (exit 137). That memory is invisible and ungovernable from the app layer.

Profiler confirmed it: peak RSS 957MiB but only 87MB Python-tracked — the rest is uvicorn/httptools socket buffers for ~125 concurrent bodies.

The fix

haproxy had only a global maxconn 4096 and no per-pod cap, so leastconn could still dump 100+ connections onto one pod. This adds:

backend s3proxy_pods
  server-template ... maxconn 40     # cap in-flight requests PER pod
defaults
  timeout queue 30s                  # excess waits for a slot, then redispatch/503

haproxy now bounds in-flight requests per pod and queues the excess (redispatching to a less-loaded pod) instead of overrunning a pod's uvicorn buffers. The app's existing limiter governs the admitted few. Both knobs are chart values (frontproxy.maxConnPerPod, frontproxy.timeouts.queue).

Why the LB, not uvicorn --limit-concurrency

• One place, all pods; no flag baked into every container.
• Queues instead of hard-rejecting — clients mostly see success, not 503s.
• Admission control / backpressure is the load balancer's job.

Proof (local, prod config: 512Mi cap / 64MB budget / 2026.6.14 app)

	direct (reproduces prod)	via haproxy maxconn 40
128×16MB PUT flood	OOMKilled, exit 137	256/256 ok, peak 335MiB
harsh mixed upload+GET flood	OOM	322MiB, no OOM

Rendered haproxy.cfg validated with haproxy -c (exit 0).

Scope

This is the upload-side OOM (the dominant cause on 2026.6.14, kill windows were PUT-heavy). Stacks on:

• fix: govern copy memory + fix passthrough-copy ClientResponse.read crash #97 (2026.6.13) — copy crash + copy-OOM
• fix: hold GET memory reservation for the whole streaming-response lifetime #98 (2026.6.14) — streaming-GET OOM