Context

The driver loads tlsCAFile / tlsCertificateKeyFile etc. once at ApplyURI time and caches the resulting *tls.Config. After on-disk cert rotation, every new connection keeps using the stale in-memory cert until process restart. Even though the rotated material is sitting on disk. Operators rotating certs out-of-band currently need to bounce the process or wire up tls.Config.GetClientCertificate themselves. This patch makes rotation transparent: the next failing handshake triggers one reload, and tlsCertificateKeyFile-based clients self-heal on the spot.

Definition of done

Add lazy TLS cert reload on handshake failure. When a new connection's TLS handshake fails and the *tls.Config was loaded from URI cert files, the driver re-reads those files once, atomically publishes the fresh config to the pool, and retries the handshake exactly once. Existing connections are not touched.

Pitfalls

What should the implementer watch out for? What are the risks?