Settle how an empty pod-level resources block behaves on 1.35 and 1.36

On Kubernetes 1.35 and 1.36.1, a pod with an empty resources: {} is classed BestEffort whatever its containers request, so Headroom leaves it alone and a container with no limit runs uncapped. On 1.37 the same pod is Burstable and Headroom manages it. This predates the gate that excludes pods with pod-level resources, which treats an empty block as unset on all of them.

Measured on kind v1.35.0 (sha256:452d707d…) and v1.37.0 (sha256:a1ed56cf…), pod requesting 100m with no limit: on 1.35, QoS BestEffort and cpu.max max at container and pod level; on 1.37, QoS Burstable and a limit of 1 CPU. A control pod with no resources field is Burstable and managed on both. The reviewer of the change that added that gate read the same as 1.35 on v1.35.5 and v1.36.1 (sha256:3489c767…). v1.36.0 was not run.

The optional admission policy rejects this shape, but it is not installed by default. By reading the code, the webhook does not check QoS, so it would seed such a pod with a limit the controller then never adjusts. That has not been run.

Measure: whether the webhook seeds this pod on 1.35 and 1.36.1, then decide whether the webhook should skip it, and whether the docs need to warn about it beyond the runbook.