Detect and remediate Karpenter node drift caused by AMI or user-data changes

Steps

1. No action needed to enable Drift itself: as of Karpenter v1.0+ (the current `karpenter.sh/v1` API), Drift is a stable, always-on disruption method with no feature gate to toggle.
2. For AMI drift, rely on EC2NodeClass spec.amiSelectorTerms (e.g. an `alias: al2023@latest`-style or tag-based selector) — when AWS publishes a new EKS-optimized AMI, EC2NodeClass status.amis resolves to the new AMI id, which no longer matches the AMI baked into already-running NodeClaims.
3. Detect drift by inspecting the `Drifted` status condition Karpenter adds to affected NodeClaims: run `kubectl get nodeclaims` or `kubectl describe nodeclaim <name>` and look at status.conditions.
4. For user-data or config changes, edit the EC2NodeClass fields directly (spec.userData, spec.blockDeviceMappings, spec.subnetSelectorTerms, spec.securityGroupSelectorTerms) or the NodePool's spec.template.spec.requirements — Karpenter recomputes a hash of the NodeClaimTemplateSpec/EC2NodeClassSpec and automatically flags non-matching NodeClaims as drifted, no manual annotation required.
5. Let Karpenter's automated Drift disruption run (it executes before Consolidation in the disruption controller's ordering) to pre-spin replacement nodes, cordon/drain the drifted ones, and terminate them, subject to spec.disruption.budgets rate limits.
6. To force faster remediation or unblock a stuck rollout, manually delete the affected NodeClaim with `kubectl delete nodeclaim <name>`, and check controller logs / node events for the specific drift reason if replacement isn't proceeding.