fix: verify-ca requires an explicit ssl_ca file

[aesslinger]

Summary

verify-ca without an explicit ssl_ca file silently fell through to with_platform_verifier() — full OS-trust-store validation — instead of erroring. The builtin driver's build_postgres_tls_connector requires an explicit CA file for this mode (platform roots aren't used, since macOS's strict EKU check rejects them) and errors clearly otherwise.

Fixes #46.

Discovery context

Found while implementing #44's fix, tracing which ssl_mode/ssl_ca combinations reach the with_platform_verifier() fallback branch. Distinct, smaller discrepancy from #44 (which was about require's cert-validation logic) — filed separately and intentionally left out of #47.

Fix

Added the same guard as the builtin, adapted to this plugin's param-name-based error convention (references ssl_ca by name, since these come from JSON params rather than a UI form):

if params.ssl_mode.as_deref() == Some("verify-ca") && user_ca.is_none() {
    return Err(
        "verify-ca mode requires an explicit CA file via ssl_ca. Platform \
         root certificates are not used for this mode. For automatic \
         platform trust, use verify-full instead."
            .to_string(),
    );
}

verify-full without ssl_ca is unaffected — that's the actual distinction between the two modes (verify-full is documented to fall back to platform trust automatically; verify-ca is not).

Testing

Manual live verification against the same self-signed-cert SSL-enabled PostgreSQL instance used for #44/#47:

Scenario	Before	After
verify-ca, no ssl_ca	{"error":{...,"message":"...error performing TLS handshake"}} (confusing)	{"error":{...,"message":"verify-ca mode requires an explicit CA file via ssl_ca..."}} ✅ (clear)
verify-full, no ssl_ca	fails (self-signed cert not in platform trust — correct)	unchanged ✅
require	succeeds (per #47)	unchanged ✅

Automated: new unit test build_tls_connector_verify_ca_without_ssl_ca_returns_a_clear_error, confirmed failing before the fix (the current code returned Ok) and passing after. Existing verify-ca-with-ssl_ca tests (verify_ca_cert_verifier_*, build_tls_connector_verify_ca_*) all still pass, confirming no regression in the actual chain/hostname validation logic.

Test plan

• cargo test --lib --bins — 114/114 pass (113 previous + 1 new)
• Manual live verification against real non-SSL and SSL-enabled PostgreSQL instances (table above)
• cargo clippy --all-targets -- -D warnings — clean
• cargo fmt --all -- --check — clean
• cargo build --release — clean
• npx markdownlint CHANGELOG.md — clean

[github-actions]

Version suggestion

Based on this PR's title (fix) and the prerelease:beta label:

Current	1.0.0-beta.7
Suggested next tag	v1.0.0-beta.8

This is informational only — no tag or release is created automatically yet.