Certificate generation skipped when internal listener TLS is disabled

https://github.com/redpanda-data/redpanda-operator/blob/operator/v25.2.1/charts/redpanda/chart/templates/_values.go.tpl#L512

Description:
The Helm chart template contains a logic flaw where the check for InternalTLS.IsEnabled short-circuits the entire listener processing loop. When internal TLS is disabled for a listener (listeners.<listener>.tls.enabled: false), the template skips creating Certificate resources for that listener's external endpoints, even when external TLS is explicitly enabled.

Impact:
Cannot use TLS only on external listeners without also enabling internal TLS
Certificate CRDs are not created for external listeners when internal TLS is disabled
cert-manager has no Certificate resources to process
No TLS secrets are generated
Pods crash with error: Could not read certificate file /etc/tls/certs/external/tls.crt

Actual Behavior: The above configuration results in NO Certificate resources being created because the internal TLS check (enabled: false) causes the entire listener to be skipped in the certificate generation logic.

Workaround: Enable internal TLS for all listeners that need external certificates:

listeners:
  kafka:
    tls:
      enabled: true   # Must enable internal TLS
      cert: external  # Use same cert for internal/external
    external:
      default:
        tls:
          enabled: true
          cert: external

Trade-off: This workaround forces TLS on internal cluster communication, which may have performance implications and requires valid certificates for pod-to-pod traffic.

Start at charts/redpanda/chart/templates/_values.go.tpl around line 512 and inspect how the internal TLS check controls listener processing. Render the chart with internal TLS disabled and external TLS enabled, then verify that Certificate resources are generated for the external endpoints; done when those resources appear without requiring internal TLS.