feat: shared default listener tls

[zachsmith1]

Today, every HTTPProxy gets a default HTTPS listener with a UID-based hostname under *.datumproxy.net, and each one triggers an individual certificate issuance via cert-manager. At scale this creates problems:

• Unnecessary load on the ACME provider — every new proxy is an ACME request, and rate limits become a real concern.
• HTTPS availability is delayed seconds-to-minutes while each certificate is issued.
• A large volume of Certificate resources must be individually tracked and renewed across every downstream cluster.

Since all default hostnames fall under a single apex domain, they can be served by one wildcard certificate instead of thousands of individual ones.

This PR introduces a defaultListenerTLSSecretName config option on GatewayConfig that lets the gateway controller reference a shared, pre-provisioned wildcard TLS secret on the default-https listener instead of requesting per-gateway certificates. Custom hostname listeners are unaffected and continue to receive their own individual certificates via cert-manager.

• When configured, the gateway controller sets CertificateRefs on the default-https listener to the shared secret and skips cert-manager annotation generation for that listener.
• TrafficProtectionPolicy certificate readiness checks are updated to skip default listeners using the shared secret, since no per-listener Certificate resource exists for them.
• This design doc covers the end-to-end infrastructure flow: central wildcard issuance on the host cluster via cert-manager (edge clusters lack DNS-01 capability), distribution to downstream clusters via Karmada, and fan-out into per-gateway ns-* namespaces via Kyverno.