Documented hardening step was a no-op: protected-mode was never off

The caching platform documentation listed "re-enable protected-mode" as a remediation step, and recorded the setting as disabled fleet-wide. Both were wrong.

protected-mode reads yes on all five instances and always has. It made no difference because of a condition that is easy to miss: protected-mode only refuses remote connections when Redis has no bind directive configured and no password. The operator starts every instance with bind 0.0.0.0 ::, an explicit bind, which disarms it entirely.

So the safety net was switched on and inert the whole time - which is why a pod in an unrelated namespace could reach the port and get a reply.

Impact: anyone following the published remediation would have performed a no-op, seen no error, and reasonably concluded the step was done. It also means protected-mode was never a viable answer to the original gap, so the only real fixes were the password (done 2026-08-19) and network isolation (open).

Documentation corrected across the platform pages. Filed so the reasoning is recorded rather than lost in a diff.