Configure Karpenter consolidation and disruption budgets to control node scale-down timing

Steps

1. Set spec.disruption.consolidationPolicy on the NodePool to `WhenEmptyOrUnderutilized` (default; also replaces underutilized nodes with cheaper ones) or `WhenEmpty` (only fully empty nodes are eligible).
2. Set spec.disruption.consolidateAfter to a duration (e.g. `1m`, default `0s`) or `Never` to control how long Karpenter waits after a pod is added to or removed from a node before considering that node for consolidation.
3. Add spec.disruption.budgets entries with a `nodes` value as a percentage or absolute count (e.g. `nodes: "20%"`) to rate-limit how many nodes can be voluntarily disrupted at once; if budgets is left undefined, Karpenter defaults to a single budget of `nodes: 10%`.
4. Scope individual budgets to specific disruption reasons using the `reasons` field (`Drifted`, `Underutilized`, `Empty`) — a budget with no reasons listed applies to all of them, and Karpenter takes the minimum (most restrictive) allowed-disruption count across all applicable budgets.
5. Add a scheduled budget by setting `schedule` (five-field cron syntax, always UTC, no timezone support) together with `duration`, e.g. `nodes: "0"` with `schedule: "0 9 * * mon-fri"` and `duration: 8h` to block disruption during business hours.
6. Apply the NodePool and verify behavior by watching Kubernetes events on nodes — Karpenter emits `Unconsolidatable` events explaining why a specific node wasn't consolidated (e.g. a blocking PDB or a lower-priced replacement not being available).