GeezerVison

Fixes #508

Problem

The fastapi benchmark (bm_fastapi) intermittently fails with
httpx.PoolTimeout when the machine running the benchmark is under heavy load.

The benchmark fires CONCURRENCY = 150 concurrent requests, but the
httpx.AsyncClient uses httpx's default max_connections = 100. The 50 requests
that exceed the pool size wait in the pool's queue for a connection to free up.
httpx's default pool timeout is 5 seconds, so when the in-flight requests take
longer than 5 seconds (which is exactly what happens under load), those 50 queued
requests exceed the pool timeout and the benchmark dies:

httpx.PoolTimeout
RuntimeError: Benchmark died
ERROR: Benchmark fastapi failed: Benchmark died

Fix

Size the connection pool to the benchmark's concurrency so that no request ever
queues:

-        async with httpx.AsyncClient(trust_env=False) as client:
+        limits = httpx.Limits(max_connections=CONCURRENCY)
+        async with httpx.AsyncClient(limits=limits, trust_env=False) as client:

With the pool sized to CONCURRENCY, all 150 requests acquire a connection
immediately, so the pool timeout can never be hit regardless of server latency.

This builds on the trust_env=False change from #505 and keeps it

Testing

Reproduced deterministically by serving the endpoint with an artificial ~6s
per-request delay and firing 150 concurrent requests:

• Before: default pool (100 connections) → httpx.PoolTimeout after ~5.1s
• After: max_connections=150 → completes successfully (~7.1s)

No behavior change in the common case: the benchmark's concurrency is a fixed
constant, so the pool is simply sized to match it.