CKS: nodeids scale-in can resize unrelated nodes to the legacy cluster offering #14458

Problem

A CKS scale-in request that identifies a worker through nodeids, without requesting an offering change, can try to resize unrelated nodes back to the cluster's legacy global offering before removing that worker.

I found this while running package-based regression tests for #14223. This is separate from that PR's live-resize reconciliation work: the offering-map fallback and the worker's decision to resize were already present in its base commit, af9764b87a6901d4dce24c34573f5d76c0441cc4. The failure was reproduced on packages from f92e52d736b9491309f6be3baac250de18c198c9; the pre-existing classification is based on source comparison, not a second deployment of the old base.

Reproduction

1. Create a Cloud-managed KVM Kubernetes cluster using a global 2-vCPU / 2048-MiB offering.
2. Configure separate offerings: one control node at 3 vCPU / 2048 MiB and two workers at 3 vCPU / 4096 MiB. The legacy global offering remains 2 vCPU / 2048 MiB.
3. Call scaleKubernetesCluster with the cluster ID and nodeids=<UUID of the additional worker>. Do not pass serviceofferingid, nodeofferings, or size.

Expected: drain and remove only the specified worker. Preserve the offerings and CPU/RAM resources of the control node and the retained worker.

Observed: createNodeTypeToServiceOfferingMap adds a DEFAULT entry from the legacy cluster offering when the request has no offering parameters. The scale worker processes CONTROL first and attempts to downsize the running control VM from 3 to 2 vCPU. The VM workflow rejects the downsize, and the requested worker is not removed. In the observed failure no VM resources or lifecycle state were changed.

The same fallback also makes a count-only request implicitly request an offering change. Omitting offering parameters should mean that existing offerings are preserved, not that a global offering change is requested.

Workaround tested

Using size=1 with an explicit current WORKER offering completed the scale-in and preserved the retained nodes. This is a worker-count operation, not a replacement for selecting an exact node. Supplying nodeids together with a worker offering is rejected by API validation, so that combination is not a workaround.

Environment

Dedicated test environment: Cloud-managed CKS, KVM, isolated network, Kubernetes 1.28.4, CloudStack development packages 24.0.0-1 from the revision above. Found during QA for #14223.