Support client certificate authentication (mTLS)

[aesslinger]

Summary

The built-in driver's mTLS bug was fixed upstream in tabularis#666: build_postgres_tls_connector in src-tauri/src/pool_manager.rs hardcoded .with_no_client_auth() across all SSL modes, so PostgreSQL servers requiring client-side certificate authentication (e.g. Google Cloud SQL with mTLS enabled) rejected connections with connection requires a valid client certificate. That PR added load_client_auth_from_pem and wires ssl_cert/ssl_key into .with_client_auth_cert(...).

This plugin has the same gap. ConnectionParams already carries ssl_cert and ssl_key (src/models.rs:19-20, populated at src/models.rs:47-48), but build_tls_connector in src/client.rs:418-447 never reads them — every branch ends in .with_no_client_auth() regardless of ssl_mode. So client-cert/mTLS connections fail here the same way the built-in driver failed before #666.

Proposed fix

Port the approach from tabularis#666 into src/client.rs:

• Add a load_client_auth_from_pem (or similar) helper that parses ssl_cert/ssl_key PEM files via rustls_pemfile/rustls::pki_types, mirroring the existing load_roots_from_pem helper (src/client.rs:451-469).
• In build_tls_connector, when both ssl_cert and ssl_key are supplied, call .with_client_auth_cert(...) instead of .with_no_client_auth() on the relevant ClientConfig::builder() chains (there are two: the verify-ca/verify-full custom-verifier branch and the platform-verifier branch).
• Add unit tests covering client cert loading and connector configuration, matching src-tauri/src/pool_manager_tests.rs from the upstream PR.
• Confirm whether ssl_cert/ssl_key should also factor into connection pool cache keying (per src/client.rs's pool caching by host:port:database:user:startup_script, noted in this repo's CLAUDE.md) — the upstream PR included ssl_cert/ssl_key in build_connection_key.

Per this repo's parity mandate, behavior should match the built-in driver's fixed implementation exactly, not diverge from it.

[aesslinger]

Implementation plan

Key finding

rustls-pki-types (already a transitive dep via rustls) exposes pem::PemObject for both CertificateDer and PrivateKeyDer (PKCS1/SEC1/PKCS8) when the alloc feature is on — which it already is transitively (confirmed via cargo tree). This repo's existing load_roots_from_pem (src/client.rs:451-469) already uses CertificateDer::pem_slice_iter via this trait. So the fix can reuse the same PemObject machinery for the private key too, via PrivateKeyDer::from_pem_slice, without adding rustls_pemfile as a new dependency (unlike upstream tabularis#666, which pulled in rustls_pemfile for this).

TDD / parity approach

Per this repo's CLAUDE.md ("prefer real Postgres over mocks... unit tests in a sibling _tests.rs file" and "read the built-in's implementation first and match its SQL/behavior exactly"):

1. Red — add test cases to src/client_tests.rs before touching build_tls_connector: successful client-cert connector construction, ssl_cert without ssl_key errors, ssl_key without ssl_cert errors, and PEM-parsing edge cases (empty cert/key file, missing file) — mirroring the existing load_roots_from_pem_* test shapes. Confirm they fail for the right reason (helper doesn't exist yet / connector silently ignores the fields).
2. Green — add a load_client_cert_from_pem helper (same shape as load_roots_from_pem) and rework build_tls_connector so both existing branches call .with_client_auth_cert(certs, key)? when ssl_cert+ssl_key are both present, .with_no_client_auth() otherwise, with upfront validation erroring on a one-without-the-other config.
3. Parity check — diff validation order and error-message class against upstream's build_postgres_tls_connector (tabularis#666): cert-without-key checked before key-without-cert, same category of error content. This plugin only has two TLS branches (not five like upstream), so match intent rather than line-for-line structure.
4. Full cargo test --lib --bins / cargo clippy --all-targets -- -D warnings / cargo fmt --all -- --check pass.

Scope decision: pool cache key

Upstream also folds ssl_cert/ssl_key into build_connection_key. This plugin's connection_key (src/client.rs:220-229) doesn't currently key on ssl_mode/ssl_ca either, so adding just ssl_cert/ssl_key would be inconsistent scope creep beyond "client certs don't work at all." Leaving connection_key unchanged in this PR; the broader TLS-param cache-key gap is pre-existing and can be tracked separately if wanted.

Will be its own PR (not folded into #24, which is an unrelated single-file justfile fix already close to merge) — both can still land in the same beta tag once merged to main.