TLS: operator's etcd client (health checks, membership) is cleartext-only

### Problem

The operator's own etcd client is cleartext-only. `MemberList` / `ClusterHealth` / `AddMember` / `PromoteLearner` / `RemoveMember` in `internal/etcdutils/etcdutils.go` build `clientv3.Config` from endpoints only, with no TLS. Once etcd is configured to serve TLS, the operator can no longer perform health checks or membership operations against its own cluster.

This is the third step of wiring TLS into the data path (after mounting certs and emitting TLS flags/scheme).

### Proposed change

Thread an optional `*tls.Config` through the `etcdutils` functions (nil ⇒ cleartext, preserving today's behavior; non-nil ⇒ set `clientv3.Config.TLS`). The controller builds it once per reconcile from the `{name}-client-tls` secret (already created by `createClientCertificate`) and passes `nil` whenever `spec.tls == nil`.

Single trailing `*tls.Config` parameter keeps the diff minimal and nil-default-compatible across the 5 in-tree call sites. Unit test asserts the nil arg reproduces today's cleartext config; the live TLS path is covered by an e2e follow-up. PR to follow.

Start in internal/etcdutils/etcdutils.go and trace its five in-tree call sites through the controller. Read how createClientCertificate creates the {name}-client-tls secret, then inspect the unit-test configuration path. Done means nil preserves cleartext behavior while a TLS config is built from the secret and used for health and membership operations.

Written by the indexing model from the issue text.