### What happened?

The caching docs still advise against `REDIS_URL` in production on performance grounds:

> we **don't** recommend using REDIS_URL in prod. We've noticed a performance difference between using it vs. redis_host, port, etc.

That guidance was correct when it was written, and it traces back to #3188. The cause was connection churn: the url path discarded the shared pool and opened roughly two new connections per request, which is ruinous over TLS because each one pays a fresh handshake.

Current code pools correctly, and the gap is gone. Measured against a local redis behind a TCP relay injecting a fixed one-way delay, with redis in the request path on every call (response caching with unique prompts, 500 requests, 50 concurrent workers):

| version | mode | req/s | connections opened | |---|---|---|---| | 1.35.17 | url | 540 | 1002 | | 1.35.17 | host/port | 742 | 50 | | current (1.95.0) | url | 650 | 50 | | current (1.95.0) | host/port | 690 | 50 |

Over TLS the old churn cost 83.9 req/s against 462.1 on current code, with 1007 connections against 52. On current code url and host/port are within run to run noise of each other, so the stated reason for the recommen…