Manager cache and job queue ignore database.redis.tls (plaintext connect, i/o timeout) #4907

Bug report:

The manager silently ignores database.redis.tls. The manager cache client (manager/cache/cache.go) and the async job queue (internal/job/job.go) build their redis clients without applying the configured TLS settings. Against a redis that requires TLS, the manager connects in plaintext, the initial ping never completes, and the pod crashloops:

failed to ping redis: i/o timeout

manager/database/database.go and scheduler/scheduler.go already apply database.redis.tls, so only the cache and job-queue clients are affected. The field is documented in docs/reference/configuration/manager.md, so config that follows the docs does not work for these clients.

Expected behavior:

When database.redis.tls is set, all manager/scheduler redis clients (including the cache and job queue) connect over TLS, and the manager starts normally against a TLS-enabled redis.

How to reproduce it:

1. Provision a redis that requires TLS (e.g. AWS ElastiCache for Valkey with encryption in transit enabled).
2. Configure the manager to use it, following the documented TLS config:

   database:
     redis:
       addrs:
         - master.example.cache.amazonaws.com:6379
       password: <auth-token>
       tls:
         caCert: /etc/ssl/certs/ca-certificates.crt

3. Start the manager.
4. It crashloops with failed to ping redis: i/o timeout. The endpoint is reachable; the client connected in plaintext to a TLS-only server, so the handshake never completes.

Environment:

• Dragonfly version: v2.5.1 (also present on main)
• OS: Linux (official manager container image)
• Kernel (e.g. uname -a): N/A (containerized, on EKS 1.35)
• Others: redis = AWS ElastiCache for Valkey 9.0.0, encryption in transit enabled; Helm chart dragonfly 1.7.6