docs: add node repair candidate resolution, admission, and escalation RFC

[sebpalmerio]

Description

This PR adds a design RFC (designs/node-repair-candidate-resolution-admission-and-escalation.md) defining candidate resolution, shared disruption admission, durable commitment, and post-reboot action resolution for Karpenter Node Repair.

Problem

Reason-aware matching can produce several eligible repair results for one Node, potentially with different actions and drain bounds. Repair may then wait behind voluntary disruption controls while health changes. Reboot adds a provider side effect that must survive controller restart and must not create an autonomous reboot loop. Karpenter needs one deterministic candidate, a clear commitment boundary, and durable attempt history without persisting reconstructible recommendations.

Proposal

• Apply durable reboot-attempt history to current eligible results before candidate resolution.
• Resolve all current eligible results for one Node into one candidate using deterministic action, driving-result, and termination-grace-period rules.
• Admit repair through shared voluntary disruption and reserve the Repair budget before commitment.
• Record reboot commitment in NodeClaim.status.repairAttempt before provider side effects, while replacement commits through NodeClaim deletion.
• Permit one reboot per NodeClaim in the initial strategy and convert later eligible reboot results to replacement through ordinary admission.

Related RFCs

• Voluntary node repair #3192
• Reboot as a Node action #3259
• Reason-aware repair policy matching #3263
• Original Node Repair design #1768

How was this change tested?

N/A — documentation/design only.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

LLMs were used in the writing of this document, but the contribution is mine.