[Feature] Support TLS for inter-node and client-to-cluster connections

### Feature description

## Summary

Redkey currently does not support TLS encryption for Redis traffic. All
communication happens in plaintext, both **between cluster nodes** (cluster bus
/ gossip and replication) and **from clients to the cluster**. We would like to
propose adding **optional TLS support** so that all Redis connections can be
encrypted.

## Problem / Motivation

Today, a `RedkeyCluster` exposes and uses unencrypted Redis connections:

- **Client → Redis**: application traffic travels in plaintext.
- **Redis → Redis**: the cluster bus (node-to-node gossip) and replication
streams are unencrypted.
- **Robin → Redis**: management commands and metrics collection are unencrypted.

This is a blocker for:

- **Compliance**: regulatory frameworks such as PCI-DSS and SOC 2 require
encryption of data in transit.
- **Zero-trust networking**: Kubernetes `NetworkPolicy` only protects at L4;
TLS adds encryption at the transport layer.
- **Multi-tenant clusters**: without TLS, Redis traffic can be observed by other
workloads sharing the network.

## Proposed Solution

Add an **opt-in, disabled-by-default** TLS configuration to the `RedkeyCluster`
CRD. When enabled, all Redis connections (client, cluster bus, replication, and
Robin management traffic) are encrypted.

High-level scope:

1. **CRD**: new `spec.tls` block referencing a Kubernetes TLS `Secret`
(`tls.crt`, `tls.key`, `ca.crt`), with an option to enable mutual TLS (mTLS)
between nodes.
2. **Operator**: when TLS is enabled, inject the relevant `redis.conf` settings
(`tls-port`, `tls-cert-file`, `tls-key-file`, `tls-ca-cert-file`,
`tls-replication yes`, `tls-cluster yes`), mount the certificate Secret into
the Redis pods, and update liveness/readiness probes to use `redis-cli --tls`.
3. **Robin**: support TLS when connecting to Redis (go-redis `tls.Config`) and
when invoking `redis-cli` subcommands (`--tls --cert --key --cacert`).
4. **Certificate management**: the operator consumes an existing Secret and does
**not** generate certificates. Certificate lifecycle is managed externally
(cert-manager recommended, with support for manual OpenSSL generation or an
external PKI such as HashiCorp Vault).

### Example CRD usage

```yaml
apiVersion: redkey.inditex.dev/v1beta1
kind: RedkeyCluster
metadata:
name: redkeycluster-sample
spec:
primaries: 3
image: redis:7.4.2
tls:
enabled: true
secretName: redkey-tls
mutualTLS: true
```

## Requirements

- [ ] TLS is **opt-in** and **disabled by default**; existing clusters keep
working unchanged.
- [ ] Encrypt **client → cluster** connections.
- [ ] Encrypt **node → node** connections (cluster bus and replication).
- [ ] Encrypt **Robin → Redis** management and metrics traffic.
- [ ] Optional **mutual TLS (mTLS)** between cluster nodes.
- [ ] Certificates are provided via an external Kubernetes `Secret`; the
operator does not generate them.
- [ ] Documented certificate workflow (cert-manager, OpenSSL, external PKI).
- [ ] Support for certificate rotation without data loss.

## Out of Scope

- Automatic certificate generation by the operator.
- Certificate authority (CA) lifecycle management.

## Additional Context

A detailed technical design (CRD changes, operator and Robin changes, certificate
generation options, Makefile integration, sample manifests, rotation, and
compatibility) is available in the internal proposal document
`09-tls-support.md`.

### Use case or motivation

_No response_

### Would you like to work on this?

Yes, I'd like to open a PR

Start with the internal proposal document 09-tls-support.md, then inspect the RedkeyCluster CRD, operator, Robin, Redis configuration, probes, Makefile, and sample manifests it identifies. Trace how configuration, Secret mounts, client connections, and cluster connections are currently assembled. Done means opt-in TLS preserves existing behavior, covers the listed traffic paths, supports rotation and mTLS requirements, and is documented with certificate workflows.

Written by the indexing model from the issue text.