feat(vmpool): add VirtualMachinePool for group VM management

[fl64]

Description

DVP has no primitive to manage a group of identical virtual machines whose count changes over time. Every "I need N identical VMs and the number varies" scenario — CI runner fleets, VDI desktop pools — is solved with orchestration outside the platform: users write their own controller/scripts that create and delete VirtualMachines, watch their number, recreate lost ones and clean up after them. This duplicates logic and is error-prone around races and node failures.

This PR introduces VirtualMachinePool (paid editions only, EE/SE+): a namespaced resource that declaratively keeps a requested number of identical VMs and integrates with kubectl scale, HPA and KEDA through the standard scale subresource. Its template is an ordinary VirtualMachineSpec, so a replica is no different from a manually created VM.

This is a draft. The feature is delivered incrementally within this single PR; phases land as separate commits. Already implemented:

• CRD VirtualMachinePool with the scale and status subresources, gated behind the VirtualMachinePool module feature gate (default off, locked off in CE).
• Controller that maintains the replica count: creates replicas from the template, replaces disappeared ones, scales down (youngest-first for now), and reports status (replicas, readyReplicas, selector, Available/Progressing). It is cache-lag-safe via a ReplicaSet-style expectations tracker, so a lagging informer cache cannot double-create anonymous replicas.

Planned in later phases of this PR: scaleDownPolicy + a /scale guard webhook, addressed scale-down (scaleDownWith), in-place template propagation, and reusable disks.

One implementation note: the controller ships only in paid editions (compiled under the EE build tag), while the CRD/API is installed in every edition; the feature gate stays locked off in CE, so the resource simply does nothing there.

Why do we need it, and what problem does it solve?

Two mass scenarios suffer most: CI/CD runners (GitLab Runner autoscaling expects a backend that can "give me N more" and reclaim idle ones) and VDI pools (warm desktops that self-heal on node failure). Without a group primitive, DVP cannot serve these natively and each team reinvents the orchestration, usually with bugs in race and failure handling. VirtualMachinePool gives users a native, declarative backend for autoscaling fleets of VMs without writing their own replica controller.

What is the expected result?

With the VirtualMachinePool feature gate enabled (EE/SE+):

1. Create a VirtualMachinePool with spec.replicas: N and a spec.virtualMachineTemplate — the controller converges the number of VirtualMachines to N.
2. kubectl scale virtualmachinepool/<name> --replicas=M (or HPA/KEDA) scales the pool to M.
3. Deleting or losing a replica triggers a replacement once the old object is gone; a member in Stopped is kept, not duplicated.
4. kubectl get virtualmachinepool and .status report replicas / readyReplicas and the Available / Progressing conditions.

Checklist

• The code is covered by unit tests.
• e2e tests passed.
• Documentation updated according to the changes.
• Changes were tested in the Kubernetes cluster manually.

Changelog entries

section: vmpool
type: feature
summary: "Add VirtualMachinePool (EE/SE+) for declarative group management of virtual machines, scalable via the standard scale subresource, HPA and KEDA."
impact_level: low