Provide SDK-owned trait for dynamic client certificates (decouple from rustls)

Context

Follow-up to #1338 / #1340.

The current client_cert_resolver field accepts Arc<dyn ResolvesClientCert>, which is a rustls trait re-exported from the crate root. This works but has drawbacks:

• Semver coupling — a rustls breaking change becomes a Temporal SDK breaking change
• Ergonomics — users must understand CertifiedKey, SignatureScheme, and has_certs() to implement the trait
• Asymmetry — the Go SDK's GetClientCertificate just returns (cert, key, error)

Proposal

Add an SDK-owned trait alongside the raw re-export:

pub trait ClientCertProvider: Send + Sync + 'static {
    fn get_client_certificate(&self) -> Option<(Vec<u8>, Vec<u8>)>; // (cert_pem, key_pem)
}

Internally, build a ResolvesClientCert adapter. This covers the 90% use case (file-watching, Vault) trivially, while the raw trait remains available for power users (HSM-backed signers).

References

• Go SDK: tls.Config.GetClientCertificate
• Review discussion: 4 reviewers independently recommended this

Start by tracing the existing client_cert_resolver field and its rustls ResolvesClientCert usage. Define the SDK-owned ClientCertProvider boundary and determine how the internal adapter should translate certificate and key PEM data while retaining the raw trait for advanced users. Done means both provider styles remain usable without exposing rustls types for the common case.