[Feature] [Application Gateway for Containers] Support ExternalName Service / external FQDN as HTTPRoute backend for SaaS multi-tenant custom domain scenarios

**Is your feature request related to a problem? Please describe.**

Application Gateway for Containers (AGFC) currently requires HTTPRoute `backendRefs` to point at in-cluster Services backed by real pod EndpointSlices. ExternalName Services and direct external FQDN backends are not supported — the ALB Controller has no pod IPs to program into AGFC's backend pool, so requests fail with HTTP 500.

This is a significant gap for SaaS multi-tenant scenarios where many customer-facing custom domains need to proxy to a single shared API surface that's already exposed at a stable hostname.

Our scenario: we run a multi-tenant SaaS platform on AKS with 100+ microservices, all consolidated behind a single shared API hostname (e.g. `api.example-platform.com`). Customers can connect using:

- **Default subdomain**: `api.example-platform.com` (we control DNS)
- **Bring-your-own domain**: `api..com` (customer controls DNS)

For each customer custom domain, we need to:

- Terminate TLS with a customer-specific cert (provisioned via cert-manager + ACME DNS-01 delegated to our zone)
- Rewrite the `Host` header to our shared upstream hostname — required so cookies, auth tokens, and service routing stay scoped consistently across all 100+ microservices (the customer browser sees the customer host; upstream services see the canonical host)
- Forward to the same internal API surface that already routes to all 100+ microservices

We do not want to recreate per-customer HTTPRoutes for every one of those 100+ microservices in every customer namespace — that's an N × M route explosion that's unmaintainable at scale.

The Gateway API specification supports ExternalName / FQDN backends. AGFC does not.

**Describe the solution you'd like**

Either of the following would solve this:

1. **ExternalName Service support as HTTPRoute backend.** ALB Controller resolves the external hostname (with periodic re-resolution honoring DNS TTL) and programs the resolved IPs into AGFC's backend pool. Combined with the existing `BackendTLSPolicy` (for SNI override) and `URLRewrite` filter (for Host header rewrite), this would give a clean Gateway-API-native model:

```yaml
apiVersion: v1
kind: Service
metadata:
name: shared-api-upstream
spec:
type: ExternalName
externalName: api.example-platform.com
ports:
- port: 443
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: customer-domain-proxy
spec:
parentRefs:
- name: customer-gateway
rules:
- filters:
- type: URLRewrite
urlRewrite:
hostname: api.example-platform.com
backendRefs:
- name: shared-api-upstream
port: 443
```

2. **A new AGFC-specific CRD** (e.g. `ExternalBackend` under `alb.networking.azure.io`) that explicitly declares an external FQDN as a backend target and can be referenced from HTTPRoute. This would parallel how `BackendTLSPolicy` and `HealthCheckPolicy` extend Gateway API today.

Either approach would let us model the customer-domain layer as pure Gateway API resources with no proxy workload to operate.

**Describe alternatives you've considered**

- **In-cluster NGINX/Envoy proxy pod** (our current workaround): we deploy a shared proxy Deployment that does `proxy_pass` to the upstream hostname, and point HTTPRoute `backendRefs` at the proxy's ClusterIP Service. This works but:
- Adds an extra TLS termination hop (AGFC → proxy pod → upstream = two TLS terminations per request).
- Requires us to operate, scale (HPA), monitor, and patch a proxy workload that exists only to satisfy AGFC's backend-pool design.
- Directly contradicts AGFC's stated value proposition of removing in-cluster proxy layers ("skip the internal NGINX pods, no extra hops or latency").
- Adds noticeable cost at scale (we expect 50+ customer domains in the next 6 months).

- **Manually-managed EndpointSlices** pointing at the upstream's resolved IP: brittle because the upstream typically sits behind a managed load balancer with IPs that can rotate without notice. Would require a custom controller to keep the EndpointSlice in sync — at which point we've built half a proxy ourselves.

- **Per-microservice HTTPRoutes duplicated per customer**: doesn't scale — 100+ microservices × 50+ customer domains = thousands of HTTPRoute resources. Unmaintainable.

- **Migrating the customer-domain layer to a different ingress** (Kong, NGINX Ingress, Envoy Gateway): splits our ingress stack across two systems, doubles operational surface area, and breaks our AGFC standardization. We'd prefer to keep AGFC as the single ingress.

- **Putting Azure Front Door in front of AGFC**: adds cost, latency, and architectural complexity for what should be a simple backend-FQDN capability.

**Additional context**

This pattern — customer custom domain → shared multi-tenant API — is foundational to nearly every SaaS platform. Examples of architectures that need it:

- Multi-tenant APIs where each tenant has a vanity or bring-your-own domain
- White-label SaaS products with custom domains per reseller
- B2B platforms exposing partner-branded endpoints
- Any scenario where cookies/auth must be scoped to a specific customer domain but backend logic lives behind a canonical hostname

Other Gateway API implementations (Istio, Envoy Gateway, Contour) support ExternalName backends natively. The absence of this on AGFC pushes SaaS workloads toward alternative ingress solutions for the customer-domain layer specifically — even when the rest of the platform runs cleanly on AGFC.

Environment:

- AKS, Azure CNI with Cilium
- ALB Controller 1.10.x (current)
- Gateway API v1.2.1
- cert-manager with ACME DNS-01 (delegated zone for customer custom domains)
- Scale: 50+ customer custom domains in the next 6 months, growing
- AGFC already in production for internal/platform traffic

Happy to provide additional architectural detail, sample manifests, or a walkthrough of the use case if helpful for prioritization.