VM as a leasable kind (KubeVirt) — distinct from CAPK/pkobe cluster workers

[jleni]

Context

A standalone lease-a-VM unit in the kind-parameterized model: the VM is the leased resource, with TTL / reset / connect / quota — distinct from:

• CAPI real-node support via ClusterClass (Proxmox/CAPMOX + KubeVirt/CAPK) #12 (KubeVirt/CAPK as CAPI worker nodes), and
• a native dedicated-control-plane backend (kobe-old#175),

where VMs are cluster nodes. Here the VM itself is the lease. This gives the closest-to-bare-metal isolation and timing as a first-class kind — the alternative to a Kata pod (#14) when you want a full VM rather than a VM-backed container.

Relationship / dedup. Reuses the KubeVirt provisioner work from #12 / kobe-old#175; this issue is specifically about exposing a VM as a leasable kind, not a cluster worker. If that turns out to be thin over the dedicated-control-plane provisioner, fold it in there instead of shipping a separate backend.

Node requirement. Same /dev/kvm / nested-virt constraint as the Kata tier in #14 (KubeVirt VMs need hardware virtualization on the host node; software-emulation fallback is too slow to be useful).

Proposal

• vm kind backed by KubeVirt VirtualMachine CRs.
• connect yields a console / SSH AccessHandle.
• reset via VM rebuild or snapshot restore.
• Pool<vm> warm-pool (shallow depth — VMs are expensive).

Acceptance

A Pool<vm> leases a KubeVirt VM to Ready with TTL + reset + connect, advertised in the #11 capability matrix.