Get decrypted connection details for a connector.

NO KNOWN CONSUMER. This docstring previously claimed an "Edit Connection Details modal" calls it; grep -rn 'connection-details' frontend/ returns zero hits, and neither the CLI (packages/) nor the tests_two harnesses call it. scripts/export_public_openapi.py:45 deliberately keeps it OUT of the published spec as an endpoint "that returns credentials or debug detail". So it is reachable but undocumented and unreferenced — which is the reason the ARD-2127 redaction below could be made unconditional without breaking a caller.

Returns only the connection_details dict with decrypted values. Does NOT include schema_structure or other connector fields.

Security:

• Requires authentication (JWT or API key) and NOTHING else: there is no require_permission gate, so every member of the org that RLS lets see the connector can read whatever this returns.

• RLS automatically enforces that user has access to this connector

• Connection details are decrypted from Azure Key Vault

• ARD-2127: the TLS PEM fields are stripped from the response unconditionally. ssl_client_key is a private key and must never be readable back out of an API that only checks authentication.

  The two CERTIFICATE fields are not secret and are not being protected here. A client certificate is presented in cleartext to the customer's database on every TLS handshake, and this PR deliberately PUBLISHES its identity — subject, issuer, validity window, SHA-256 fingerprint — as source_metadata.source_tls_client_certificate, which GET /v1/connectors and GET /v1/connectors/{id} return to a wider audience behind the same auth class (_public_connector_response strips only source_in_eks_vpc). They are excluded from this endpoint only to keep ONE rule for all three PEM fields rather than a per-field carve-out that drifts the next time a field is added — and because nothing consumes them here.