feat(vpa): thread prediction store through disruption path

[jigisha620]

Description
Threads the VPA prediction store through the disruption path so that consolidation and drift use predicted post-eviction resource requests instead of current ones. When a VPA recommends higher (or lower) resources for a workload, Karpenter now accounts for what the pod will actually request after recreation rather than what it currently has.

Changes

• Disruption integration - Pass predictionStore through the Provisioner so that disruption's SimulateScheduling uses predicted requests when evaluating if evicted pods fit on replacement nodes.
• Workload prediction resolution (prediction.go) - PredictedRequests resolves a pod's owner chain (Pod → RS → Deployment, Pod → StatefulSet, Pod → DaemonSet, Pod → Job → CronJob) and replaces its requests with VPA predictions where available. Pods without predictions or without recognized owners fall back to current requests.
• DaemonSet overhead prediction - When consolidation creates a new replacement node, buildDaemonOverheadGroups uses predicted DaemonSet overhead. This does NOT apply to existing destination nodes (their DS pods stay as-is and aren't recreated).
• PodForDaemonSet OwnerReferences - The synthetic pod generated from a DaemonSet template now includes OwnerReferences to the DaemonSet, matching what real DS pods have. This allows resolveTarget to resolve the synthetic pod back to its DaemonSet for prediction lookup.
• RBAC - Added batch/jobs get/list/watch to the KWOK chart clusterrole for Job → CronJob resolution.

How was this change tested?
Added unit tests for PredictedRequests covering all owner resolution paths, multi-container pods, partial predictions,
and new resource injection. Added disruption integration tests covering consolidation blocked/enabled by predictions, DaemonSet overhead predictions, partial predictions, lower-than-current predictions, and drift replacement sizing.

Tested on a live cluster with a NodePool allowing c5.xlarge (4 CPU) and c5.large (2 CPU). Consolidation attempts to replace underutilized c5.xlarge nodes with cheaper c5.large nodes.

• Workload prediction blocks consolidation - Pod requests 100m, VPA predicts 3 CPU. Consolidation blocked because predicted 3 CPU exceeds c5.large capacity (~1.9 allocatable).
• VPA deletion unblocks consolidation - After deleting the VPA, prediction cleared and consolidation proceeded to c5.large.
• Lower prediction enables consolidation - Pod requests 3 CPU (stuck on c5.xlarge), VPA predicts 1 CPU. Consolidation triggered replacement with c5.large since predicted 1 CPU fits.
• DaemonSet prediction blocks consolidation - Workload pod (1 CPU) + DaemonSet VPA predicts 1.5 CPU. Total 2.5 CPU exceeds c5.large capacity, consolidation blocked.
• DS VPA deletion unblocks consolidation - After deleting the DS VPA, consolidation proceeded.

AI Disclosure: This PR was developed with AI assistance. Per the project's AI contribution policy, this is disclosed here. I have reviewed and tested all the code .

[kubernetes-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: jigisha620
Once this PR has been reviewed and has the lgtm label, please assign derekfrank for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment