KEP-2941 states DeviceClass mapping uniqueness as absolute, but the validator already relaxes it for distinct counters

### What happened: The DRA KEP states DeviceClass mapping uniqueness as absolute, and lists relaxing it as work still to come. The validator already implements the relaxation. `keps/2941-DRA/README.md`: ``` 323: - Device class uniqueness is enforced - each device class can only map to one resource name to prevent quota ambiguity. 612: requires relaxing this uniqueness constraint and is deferred to beta. 1679: mappings due to the DeviceClass uniqueness constraint across mappings. ``` and in the `KueueDRAIntegrationPartitionableDevices` Beta criteria: ``` 2267: - support multi-counter tracking by relaxing the DeviceClass uniqueness constraint 2268: across mappings when both have counter sources with different counter names, 2269: allowing memory and compute as separate quota resources for the same DeviceClass ``` `pkg/config/validation.go` already does exactly that: ```go counterName := counterNameForMapping(mapping) if existingResource, exists := deviceClassToResource[deviceClass]; exists { if existingResource != mapping.Name { // Allow same DeviceClass in multiple mappings only when both have // counter sources with different counter names — each mapping tracks // a different counter dimension (e.g., gpu.memory and gpu.compute). existingCounters := deviceClassCounterNames[deviceClass] switch { case counterName == "" || existingCounters.Len() == 0: allErrs = append(allErrs, field.Invalid(dcPath, deviceClass, fmt.Sprintf("device class already mapped to resource %s", existingResource))) case existingCounters.Has(counterName): ... default: deviceClassCounterNames[deviceClass].Insert(counterName) } } } ``` That landed in #13018 ("Address PD beta graduation criteria for ResourceSlice caching, multi-counter tracking, and ConsumesCounters iteration"), which is where the criterion was met. The KEP was not updated with it. **What you expected to happen**: An administrator reading the KEP to find out whether one DeviceClass can back both a memory and a compute quota dimension is told it cannot, and that the answer is deferred to Beta. The configuration accepts it. **How to reproduce it (as minimally and precisely as possible)**: A Configuration with two counter-backed mappings over one DeviceClass and distinct counter names passes `validateResourceTransformations`' sibling check in `pkg/config/validation.go`; the KEP text says it does not. **Anything else we need to know?**: I noticed this while working on the prioritized-list section of the same KEP and did not touch it there, since it belongs to `KueueDRAIntegrationPartitionableDevices` rather than to that work. The fix looks like three prose sites plus moving the Beta bullet into the delivered list, so it seemed better raised than folded into an unrelated PR. The absolute statement is still correct for count-based mappings, which is probably the shape the wording should take. /kind documentation /area dra