Debug a suspected race condition in concurrent code

Shared mutable state: `connectionPool.activeCount` (int, incremented/decremented without a lock) and `cache map[string]*Entry` (accessed by multiple goroutines, no mutex). Constructed interleaving matching the symptom (intermittent 'connection limit exceeded' despite count appearing under limit in logs): Goroutine A reads `activeCount` (currently 9), Goroutine B also reads 9 before A's increment lands, both proceed thinking they're under the limit of 10, both increment, actual count becomes 11 with no error, matches your symptom of occasional over-limit connections under load. Top candidate: the unsynchronized read-then-increment on `activeCount`. Fix: replace the int with `atomic.Int32` and use `CompareAndSwap` for the limit check, rather than a full mutex, since this is a single counter and doesn't need to serialize other pool operations. Deadlock check: this fix doesn't acquire any lock, so no deadlock risk from this change specifically; the separate `cache` map issue is a different race, lower priority since it doesn't match your reported symptom, worth a follow-up with `sync.RWMutex` once this is confirmed fixed.