fix: accept Opaque secrets for mTLS auth

[ConnorGraham]

What was changed

Relax the secret type check in ParseClientSecret to accept both kubernetes.io/tls and Opaque secret types for AuthModeTLS. Update the MutualTLSSecretRef field comment in the CRD types to reflect the expanded accepted types.

Why?

Previously, the controller enforced type: kubernetes.io/tls for mTLS secrets. This blocked organizations that store TLS credentials in Opaque secrets — a common pattern when bundling tls.crt, tls.key, and ca.crt into a single secret (e.g. multi-file cert-manager outputs, or any tooling that produces a keypair alongside a custom CA).

The kubernetes.io/tls secret type natively supports only two keys (tls.crt and tls.key), so teams needing to include a CA cert alongside the keypair must use Opaque. The downstream handler fetchClientUsingMTLSSecret already accesses secret data by key name and works correctly with either type — only the type guard was blocking it.

Checklist

1. Closes [Bug] ParseClientSecret rejects Opaque secrets for AuthModeTLS #275

2. How was this tested:

Unit test TestParseClientSecret_OpaqueSecretType (renamed from TestParseClientSecret_WrongSecretType) now asserts that an Opaque secret containing tls.crt and tls.key is accepted and produces a valid ClientAuth with AuthModeTLS. All 316 existing tests continue to pass.

3. Any docs updates needed?

MutualTLSSecretRef field comment in api/v1alpha1/temporalconnection_types.go updated to document both accepted secret types.

[CLAassistant]

All committers have signed the CLA.