fix(nodes): route load balancer traffic according to externalTrafficPolicy

[sircthulhu]

Problem

RobotLB always picks target nodes from where the service's pods run, which is the
behaviour of externalTrafficPolicy: Local. Services using the default Cluster
policy therefore lose every node that kube-proxy could have forwarded from.

This breaks a service whose only pod runs on a node where its own nodePort is not
reachable. A KubeVirt VM behind a LoadBalancer service hits exactly this: the VM's
nodePort answers on every node except the one hosting the VM, and since that node was
the load balancer's only target, the target stayed unhealthy and every connection was
accepted and immediately closed. HTTP services on the same cluster kept working only
because their deployments have replicas on several nodes.

Changes

Node selection

• Target nodes follow the service's externalTrafficPolicy. Cluster, the Kubernetes
  default, uses every node of the cluster; Local keeps the previous pod-based
  discovery. ROBOTLB_DYNAMIC_NODE_SELECTOR=false still selects nodes by the
  robotlb/node-selector annotation.
• Nodes labelled node.kubernetes.io/exclude-from-external-load-balancers, which
  kubeadm puts on control-plane nodes, stay out of every balancer under either policy.
  Cordoned and not-ready nodes are dropped under Cluster, where they would only take
  up target slots.

Targets

• Targets are planned before they are applied: deduplicated, sorted, and trimmed to the
  number the balancer type holds, so a cluster larger than the limit keeps a stable set
  of targets instead of retrying calls the API will reject.
• A target Hetzner rejects, such as an IP outside the vSwitch subnet of the attached
  network, no longer aborts the reconciliation and no longer fails every later run.
  Reconciliation fails only when the balancer is left without a single live target, and
  the error carries the reason the API reported.

Services without a usable port

• A Hetzner load balancer forwards traffic to a node IP, so a port is reachable only
  through its nodePort. A service whose ports all lack one no longer gets a balancer
  created for it — it used to get an empty one, billed by the hour — and a service that
  already advertises an external IP loses it, so nothing keeps sending traffic to a
  balancer that no longer forwards.

Tests

• cargo test covers target planning, node selection, node eligibility and port
  mapping. The repository had no test module before, and cargo test is now part of the
  pre-commit hooks the CI workflow runs.

Upgrade impact

Cluster is the Kubernetes default, so services that never set externalTrafficPolicy
get the full node list on upgrade, which rewrites the targets of their existing
balancers.