docs(dr): reflect the stable floating-IP API endpoint in the DR runbook

[devantler]

🤖 Generated by the Daily AI Assistant

Follow-up to #2492 / #2120 (stable floating-IP API endpoint, landed in #2524).

Problem

docs/dr/runbook.md predates the floating-IP endpoint. It states (Scenario 9, and the notes at the top / after Scenario 4) that "after a rebuild the cluster has a new API endpoint" — but with floatingIPEnabled: true the prod API endpoint is now a stable Hetzner floating IP, so at least a control-plane node recreate (the #2120 case) no longer changes it. The runbook should say so, so an operator doesn't needlessly refresh KUBE_CONFIG for an endpoint that didn't move.

Verify before writing (the open question)

Confirm what actually survives which recovery path before editing this critical runbook:

• CP recreate (single CP replaced): endpoint should now be stable (floating IP re-attaches) — only client certs/PKI unaffected. Likely a new short scenario or a note.
• Full rebuild (Scenario 4, brand-new cluster): does DR - Rebuild Prod re-attach the same floating IP to the new CPs, or mint a new endpoint? If it re-attaches, KUBE_CONFIG's server URL stays valid and only the Talos PKI changes; if not, Scenario 9 stands as-is.

Acceptance criteria

• Verify the floating-IP behaviour across CP-recreate vs full-rebuild (check .github/workflows/dr-rebuild.yaml + the floating-IP resource lifecycle).
• Update the runbook's endpoint-change wording to match, distinguishing the two paths.
• No speculative claims — only documented, verified behaviour.

[devantler]

🤖 Generated by the Daily AI Engineer

Live/source verification found that this documentation change is not safe to land yet; the stable-client premise has two named KSail blockers.

1. The VIP is not active on prod yet. Platform's normal deploy path runs cluster update. The merge-queue deploy for feat: enable the Hetzner floating-IP stable API endpoint on prod #2524 completed with ℹ No changes detected, and the current control-plane machine config still has the old node endpoint with no VIP block. This is the exact silent no-op tracked by devantler-tech/ksail#5947; draft devantler-tech/ksail#6034 implements update-time floating-IP drift detection, attachment, VIP grafting, and rolling-recreate handling.
2. Fresh creates still save a node-bound kubeconfig. KSail main renders the floating IP into the Talos/Kubernetes bundle, but saveHetznerKubeconfig then unconditionally rewrites the saved kubeconfig server: to the first control-plane node's reachable IP. The current prod KUBE_CONFIG and TALOS_CONFIG are likewise node-addressed. This newly verified gap is tracked by devantler-tech/ksail#6043.

Until both paths are fixed and deployed, the runbook must not promise that a control-plane recreate leaves KUBE_CONFIG usable. The verified unblocking sequence is:

• merge/release #6034, bump Platform's KSail pin, deploy, and confirm the owned floating IP exists, the VIP block is live, and the API answers on it;
• fix/release #6043 and refresh KUBE_CONFIG so its server: is the floating IP;
• then update Scenario 1/4/9 with the final matrix: CP recreate preserves endpoint+PKI; full rebuild reuses a surviving owned floating IP but creates new PKI; cluster delete/floating-IP loss changes both endpoint and PKI.

No runbook edit was committed from this verification pass.