redis5: component definitions advertise unsupported TLS

[weicao]

Problem

Redis 5.0.12 does not provide the TLS server/client capability used by the addon, but the Redis 5 data, cluster, and sentinel ComponentDefinitions advertise spec.tls.

With tls: true, KubeBlocks injects REDIS_CLI_TLS_CMD=--tls --insecure while the Redis 5 startup scripts still launch plaintext Redis. In one exact runtime reproduction, all three Redis 5 shard Pods exhausted 30 readiness attempts because redis-cli rejected --tls; plaintext password-auth PING remained healthy. The failure occurred before the partial-join injection.

Canonical runtime evidence was independently verified: outer SHA256 6b055579c5ab537bb2d76eac9d89120ec572b1dd57ddb9b3dd40272587ab997c; inner manifest SHA256 9546fa041b9e671aee93c931733d379cf2721610d473cdc834bbe875739f05c0, 27/27 files verified after normalizing the archived prefix.

Expected contract

• Redis 5 data, cluster, and sentinel definitions must not advertise TLS.
• A Cluster requesting TLS with a Redis 5 definition must fail closed before workload creation, with no silent plaintext downgrade.
• Redis 6, 7, and 8 must retain their existing TLS contract.
• The immutable definition identity must advance instead of changing the old published objects in place.

Validation

• Structured Helm/YAML contract over the exact 12 Redis family/version ComponentDefinitions.
• Redis 5 TLS absent; Redis 6/7/8 TLS structure unchanged.
• Exact cardinality and name multiset reject extra, missing, duplicate, or substituted definitions.
• Runtime negative gate requires the unsupported-TLS condition and zero Pods/InstanceSets.

This records the Redis 5 capability mismatch only. It does not establish a Redis 6/7/8 regression.