perf: hold a long-lived MultiplexedConnection in Valkey adapters

[ttatsato]

Problem

Both Valkey adapters call client.get_multiplexed_async_connection().await on every operation:

• src/adapters/auth_cache/valkey.rs:27 (get), :36 (set), :49 (delete)
• src/adapters/rate_limiter/valkey.rs:160-164 (try_acquire), :201-205 (get_usage)

redis::Client is essentially a connection factory. While redis 1.2 internally reuses the multiplexer in many cases, the call still goes through synchronization on every request and the adapter's intent is unclear from the code. The idiomatic pattern is to acquire the MultiplexedConnection once and clone it as needed (clones are cheap — internally Arc-backed).

This is on the auth + quota hot path of every proxied request, so it is worth tightening even though it is unlikely to be a 10× factor on its own.

Proposed fix

• In ValkeyAuthCache::new and ValkeyRateLimiter::new, acquire the MultiplexedConnection once and store it on the struct.
• In each method, clone the stored connection (self.conn.clone()) instead of calling get_multiplexed_async_connection().await again.
• Keep the startup PING as the connectivity check.

Notes

• Reconnect behavior on Valkey restart should be sanity-checked after the change; MultiplexedConnection reconnects under the hood, but worth confirming with a manual restart test.