proxy: allow service updates while long-lived requests are active

Summary

ServeHTTP holds servicesMtx.RLock across service matching, authentication, external store/pricer calls, and the full reverse-proxy response. UpdateServices needs the write lock.

A hung backend request or long-lived gRPC/streaming response can therefore prevent configuration updates indefinitely.

Impact

One request can block operational changes such as updating a backend, changing authentication policy, or deploying an emergency configuration. This is especially problematic for services intended to maintain long-lived streams.

Proposed direction

Publish immutable service/backend generations:

1. Acquire the read lock only long enough to capture the current generation.
2. Release it before authentication and backend I/O.
3. Track generation references while requests use it.
4. Retire and clean up old generation resources after their references drain.

This should be coordinated with transport/pricer retirement so shortening the lock does not close resources still used by requests or metering reports.

Acceptance criteria

• A long-lived request on generation A does not prevent publishing generation B.
• The request continues safely on generation A.
• New requests use generation B immediately after publication.
• Retired resources are eventually reclaimed without races.

Start by reading the ServeHTTP and UpdateServices entry points described in the issue, focusing on the service lock, generation lifetime, and transport/pricer cleanup. Trace how requests retain backend resources and how updates publish configuration. Done means generation B is immediately used by new requests, generation A remains safe for active long-lived requests, and retired resources are reclaimed without races.