Allow `gateway.envoyproxy.io/sds` secrets in listener `tls.certificateRefs`

Summary

#8745 added the gateway.envoyproxy.io/sds secret type so a BackendTLSPolicy.validation.caCertificateRefs can point at an SDS endpoint instead of an inline CA bundle. The XDS translator path under internal/xds/translator/listener.go already accepts cert.SDS != nil for downstream listener server certs, but the Gateway API front-end never populates that field when processing listener tls.certificateRefs, and the validation pipeline rejects non-kubernetes.io/tls secrets before the IR is built. As a result, listener server certs cannot be supplied via SDS today.

Use case: a SPIRE workload API socket mounted on the envoy proxy pod issues short-lived SVIDs with the listener hostname as a DNS SAN. With this gap closed, listener certs come straight from the workload API and cert-manager is no longer required to mint per-listener certs.

Reproduction

apiVersion: v1
kind: Secret
metadata:
  name: demo-sds-ref
  namespace: demo
type: gateway.envoyproxy.io/sds
stringData:
  url: /run/spire/sockets/api.sock
  secretName: spiffe://example.pki/workload/demo-pki-gateway
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: demo-pki-gateway
  namespace: demo
spec:
  gatewayClassName: envoy
  listeners:
    - name: https
      port: 443
      protocol: HTTPS
      hostname: demo.example.pki
      tls:
        mode: Terminate
        certificateRefs:
          - kind: Secret
            name: demo-sds-ref
      allowedRoutes:
        namespaces:
          from: Same

The envoy proxy pod has the SPIRE workload API UDS mounted at /run/spire/sockets/api.sock (via the SPIFFE CSI driver) and a matching ClusterSPIFFEID issues an SVID with demo.example.pki as a DNS SAN.

Observed

Gateway is Accepted=True and Programmed=True, but the listener reports:

status:
  listeners:
    - conditions:
        - type: ResolvedRefs
          status: "False"
          reason: InvalidCertificateRef
          message: |-
            No valid secrets exist: certificate refs 0:
            Secret demo/demo-sds-ref must be of type kubernetes.io/tls.

Expected

The SDS-typed secret is accepted on listener tls.certificateRefs, the IR carries cert.SDS populated from the secret's url + secretName, and processSDSClusters emits an SDS cluster pointing at the configured UDS so the proxy fetches the listener cert from the workload API.