feat(redisconn): add CACertFile to TLSConfig

[reyortiz3]

Summary

redisconn.TLSConfig only accepts a CA bundle as bytes (CACert), so every consumer that configures Redis TLS from a file has to read, empty-check and validate the bundle itself before calling BuildTLSConfig. toolhive does exactly this in pkg/redisconfig, alongside a second, parallel serializable TLS type for the auth server.

This adds CACertFile so the library owns file loading, with the same strictness consumers already apply by hand.

• BuildTLSConfig reads CACertFile when set. A missing, empty, or malformed file is an error; it never falls back to system roots or plaintext.
• CACert and CACertFile are mutually exclusive.
• Config.Validate() stays free of filesystem access; the file is read when the TLS configuration is built (which NewClient reaches).
• InsecureSkipVerify and CACertFile gain json/yaml tags (insecureSkipVerify, caCertFile) so the type can be used in serialized configuration. Decoding stays compatible; encoding InsecureSkipVerify now emits the camelCase key.
• The deprecated redis package aliases this type and picks up the field automatically.

Type of change

• New feature
• Bug fix
• Breaking change

Test plan

• go test -race for redisconn, including a new table-driven TestBuildTLSConfigCACertFile (valid, missing, empty, malformed, and both fields set)
• task lint (0 issues) and task license-check

Notes for reviewers

• The PEM byte fields (CACert, ClientCert, ClientKey) are intentionally left untagged. Serializing key material should be a deliberate decision, so the struct is partly tagged for now.
• The CA file is read once when the TLS configuration is built; changing its contents requires a new client.
• redisconn is released as its own module, so consumers need a new redisconn release to use this.

🤖 Generated with Claude Code