fix: transparently recover pre-0.7 load balancers after upgrade

[pando85]

Problem

0.6.x named Hetzner LBs after the Kubernetes Service (kube-apiserver-lb), while 0.7.x changed the default to <service>.<namespace> and added UID ownership. The 0.7.1 adoption logic only checks namespace-qualified names, so an existing private-only LB can be missed. If 0.7.x has already created a replacement LB, its attempt to attach the original static private IP fails with Hetzner 422 ip_not_available.

Fix

• Recognize the original 0.6.x bare Service name, including with ROBOTLB_CLUSTER_NAME set, while preserving strict finalizer + ingress-address ownership evidence.
• If 0.7.x has already provisioned a new UID-owned LB, independently locate the matching original and only discard the replacement if it has exactly the expected UID label and no private networks, services, or targets. Re-fetch both by name and immutable LB ID before deleting anything.
• Defer regular reconciliation until Hetzner confirms replacement deletion; adopt and label the original LB on the next successful attempt without renaming or changing its network, listeners, or targets.
• Fail closed for non-empty, ambiguously owned, or changed resources; add regression tests for private-only bare-name adoption, disabled/foreign evidence, and replacement safety checks.

No version bump or release changes.

Incident reproduced from customer symptoms

Existing Service kube-system/kube-apiserver-lb has robotlb/lb-private-ip: 172.29.0.1; the original Hetzner LB kube-apiserver-lb still owns it. 0.7.x creates kube-apiserver-lb.kube-system and Hetzner returns 422 ip_not_available on network attachment.

Validation

• Regression unit tests added for discovery and deletion guard invariants.
• CI should run cargo fmt, clippy (-D warnings) and tests. No local Rust toolchain is available in this execution environment, so GitHub CI is the validation gate before merging.