DRA: Capacity Requests for Extended Resource Mapping

KEP-5004 (DRA Extended Resource) lets a DeviceClass declare an extendedResourceName, so that a container's classic resources.requests/resources.limits entry (e.g. nvidia.com/gpu: 1) is satisfied by devices published through a DRA driver. The scheduler synthesizes a ResourceClaim on the pod's behalf, with one DeviceRequest per container per extended resource, requesting Count devices with the default capacity consumption from the matching DeviceClass. KEP-5075 (DRA Consumable Capacity) lets any DeviceRequest carry a Capacity field (a CapacityRequirements map of capacity name to requested quantity), so that a device advertising allowMultipleAllocations: true is only partially consumed by the allocation instead of being handed out with the default capacity consumption. These two features do not currently compose. The DeviceRequest the scheduler synthesizes for an extended resource never sets Capacity, so extended resources can only ever request devices with the default capacity consumption. This KEP adds an optional extendedResourceCapacityRequests field to DeviceClassSpec. When set, the scheduler copies its value onto the Capacity field of every ExactDeviceRequest it synthesizes for that class's ExtendedResourceName, reusing the existing CapacityRequirements type and the existing per-allocation semantics of DeviceRequest.Capacity as-is. No new allocation algorithm, no new API type, and no change to how a pod expresses its request. The extended resource name is what changes behavior, exactly as it already does today for which DeviceClass gets selected. This lets a cluster administrator expose a fixed-size "slice" of a shareable device (for example, a fixed number of GPU time-slicing shares) through the classic extended resource API, enabling drop-in migration of extended-resource-based workloads (no pod spec changes) o