Stop reconnect churn after a cached Redis Cluster rejection #133

Problem

Follow-up from the review of #132 at 95792a3.

The first successful connection classifies the endpoint with CLUSTER INFO and caches InitialServer::Unsupported when Redis Cluster is detected. Later RedisConnection::connect() calls still construct a standalone client and send PING before consulting that cached result in acceptStandalone().

For a Cluster endpoint, failed adapter reads and writes continue requesting reconnects. This can create a fresh connection and PING on every attempt, potentially about every 100 ms, even though the endpoint is already known to be unsupported.

Desired behavior

• Return false before network setup when the cached mode is Unsupported.
• Preserve the one-time CLUSTER INFO classification for the initial reachable endpoint.
• Keep reconnects to accepted standalone endpoints free of repeated mode probes.

Acceptance criteria

• Repeated connect() calls after a cached Cluster rejection open no additional sockets and send no additional PING or CLUSTER INFO commands.
• The cluster-refusal proxy regression expects one initial PING, one CLUSTER INFO, and no writer publication.
• Standalone connection, reconnect, reader-recovery, and sanitizer suites remain green.

Related: #65 and #132.