Finish the network load balancer cell path #720

The load balancer stack (#624, #712 to #716) publishes a NetworkLoadBalancerCellIntent for each cell, but nothing on a cell acts on it yet. Four pieces are still missing before a customer's load balancer works end to end and the hub stays bounded.

• Cell consumer. No code on a cell reads NetworkLoadBalancerCellIntent. The feat: Tell serving locations what load balancers need #716 body and docs/plans/network-load-balancer-cell-contract.md say "the location validates this". Build the consumer, or reword both to say the intent is published and propagated only.

• Backend health producer. Nothing creates the NetworkLoadBalancerBackendHealth objects that feat: Health-check load balancer backends #715 reads. Until something does, every backend's health is unknown.

• Tell the customer about the 64-backend limit. internal/controller/networkloadbalancercellintent_controller.go:248 withdraws an intent with more than 64 endpoints without setting a route condition. The customer sees AwaitingDataPlane and never learns why. Set a condition such as UnsupportedCapability that names the limit.

• Delete withdrawn intents. internal/controller/networkloadbalancercellintent_controller.go:326 leaves every Withdrawn intent on the hub, even after the route is deleted and its finalizer is gone. Churn in routes or VIPs grows the hub without bound. Delete them once the cell acknowledges the withdrawal, or on route deletion.

• Stop idle health rewrites. With no dialer, each sweep still stamps LastProbeTime and rewrites NetworkLoadBalancerBackendHealth status every 5s. Skip the write when nothing changed.

Related to #716, #715