[Feature] Container-native Azure Load Balancer

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

Azure Load Balancer targets nodes, not pods. That mismatch causes four recurring problems for AKS workloads:

- Extra hops and latency. Traffic lands on any node in the cluster and is then forwarded to the node holding the pod, via kube-proxy or a proxy ingress controller. This adds latency and creates SNAT contention on high-QPS paths.
- Source IP is lost. With externalTrafficPolicy: Cluster, the proxy hop strips the client source IP. Preserving it requires externalTrafficPolicy: Local, which introduces its own failure mode.
- Traffic blackholing. With externalTrafficPolicy: Local, the load balancer can send traffic to nodes that no longer host a healthy pod, because health is evaluated at node level. Requests are dropped until probes catch up.
- Session instability. Affinity is node-based, so pod rescheduling, scaling, or node rehash breaks sticky sessions.

**Describe the solution you'd like**

A container-native LB that enables direct, high-performance load balancing to container endpoints (pods), reducing latency and improving reliability by bypassing node-level proxies and providing granular health checks and session affinity at the pod level. This would result in faster traffic delivery, better failover, and more efficient scaling for modern, containerized applications.

**Describe alternatives you've considered**

- Standard Load Balancer with externalTrafficPolicy: Cluster. Even traffic spread, but the proxy hop strips source IP and adds latency.
- Standard Load Balancer with externalTrafficPolicy: Local. Preserves source IP, but blackholes traffic when a node has no healthy pod, and concentrates load when pods are unevenly distributed.
- Application Gateway for Containers. Fully managed and pod-aware, but operates at Layer 7. This request is for Layer 4, where workloads need direct TCP and UDP handling rather than HTTP-aware routing.