AdmissionFairSharing: LocalQueue with fairSharing.weight: 0 jumps to the front of the admission queue

**What happened**: Wiith AdmissionFairSharing enabled and set fairSharing.weight: 0 on a LocalQueue, expecting that queue to be deprioritized. The weight field documents this : "A zero weight implies infinite share value, meaning that this Node will always be at disadvantage against other ClusterQueues and Cohorts." But in practice we saw the opposite: while the zero-weight queue is idle, its workloads consistently win admission ahead of every other queue. The cause is a division by the weight without guarding for zero. Admission order is driven by a per-LocalQueue usage score computed as usage / weight in CalculateUsage (pkg/util/admissionfairsharing/admission_fair_sharing.go). When the weight is 0: - idle queue: 0 / 0 = NaN - active queue: usage / 0 = Inf That score is then compared with cmp.Compare in the admission ordering (queueOrderingFunc, pkg/cache/queue/cluster_queue.go). cmp.Compare orders NaN below every real number, so an idle zero-weight queue sorts to the very front of the admission heap and gets served first. Once it admits a workload and starts accumulating usage, the score becomes +Inf and it drops to the back, so the queue oscillates between first and last on each cycle. **What you expected to happen**: A zero-weight LocalQueue should always be last in the admission order, matching both the ClusterQueue behavior and the documented meaning of weight: 0. **How to reproduce it (as minimally and precisely as possible)**: 1. Enable AdmissionFairSharing. 2. In one ClusterQueue, create two LocalQueues; set spec.fairSharing.weight: "0" on one of them. 3. Submit pending workloads to both queues. 4. Observe that the zero-weight queue's workloads are admitted first while it is idle.