In-place Node Resource Resize

This proposal facilitates dynamic native resource resizing (increases and decreases in capacity) on a node to streamline cluster capacity updates, offering a seamless alternative to adding or removing nodes from an existing cluster. The revised node configurations automatically propagate at both the node and cluster levels. Today, mutating Node.Status.Capacity is not a supported or safe operation in Kubernetes. The Kubernetes ecosystem (Scheduler, Cluster Autoscaler, VPA, Quota system) has never been explicitly designed or tested to tolerate a live change to a Node's capacity values. This KEP addresses the problem in two ordered layers: Layer 1 — Ecosystem Tolerance: Formally define the contract that the broader cluster ecosystem must honour when Node.Status.Capacity changes. Establish the API-server mutations, Scheduler cache-invalidation tests, Cluster Autoscaler behaviour validation, and Quota/VPA integration points that make a capacity change safe to propagate — even if, as a first step, that change is initiated by a Kubelet restart. This is the scope of the v1.38 Alpha milestone. Layer 2 — Declarative Capacity Actuation: Introduce Node.Spec.ConfiguredCapacity, the declarative API field that allows external controllers to trigger a capacity change. Implement the Kubelet reconciliation loop that updates cgroups, re-initialises sub-managers (CPU Manager, Memory Manager), recalculates container swap limits via the CRI, and synchronises Node.Status — all on the running node. The CapacityConfigured Node Condition disseminates the live reconciliation state to external orchestrators. This layer is fully described in this KEP and targets a subsequent milestone (v1.39 Alpha or later), pending resolution of the open design questions documented in Open Questions for Layer 2. The full design of Layer 2 — including the Node.Spec.ConfiguredCapacity API field, the Kubelet reconciliation loop, and the CapacityConfigured c