Let a fractional LimitRange ratio cap reach the tight split

Under a fractional per-container maxLimitRequestRatio, a very small request holds a pod's cap at its total request, even though a higher target would split inside the rule. internal/eligibility/eligibility.go:322:func containerRatioCapMilli stays safe by keeping every share at or below a whole limit, however the remainders fall.

Measured on envtest 1.37. Both pods predate the LimitRange, and the specs in internal/controller/node_controller_limitrange_test.go pin both shapes:

Requests	Ratio	What happens	Admitted directly
100m + 10m, memory-pinned	1.05	The cap is 110m, the QoS floor of 120m is refused on every attempt, and limitrange-denied keeps rising	115m
1000m + 10m	1.05	The limit falls to 1010m, so the pod gets no burst	1060m

A pod created under the ratio stays where it started in the first shape, because 120m sits inside the deadband. The cost is usually a few millicores, and a whole-number ratio is exact. In a reviewer's sample of 64 random shapes, none were refused at the cap, and the gap to the largest admitted target was mostly 1m to 3m.

The likely shape is to walk down from ratio × total to the first target whose split fits every container's limit. That needs splitLimit's rounding, which lives in internal/controller/podinput.go, while the cap is computed in internal/eligibility. Update the design, runbook and pinned specs when this lands.