fix(vm): clarify missing default VirtualMachineClass error

[eofff]

Description

Changed the VM mutating webhook behavior for VirtualMachines created without spec.virtualMachineClassName. If no default VirtualMachineClass is configured, the VM class defaulter now returns an explicit error instead of leaving the field empty and letting CRD schema validation produce a generic should be at least 1 chars long message.

Updated the VM defaulter unit test to cover this missing default class case.

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

When a user applies a VM manifest without spec.virtualMachineClassName and the cluster has no default VirtualMachineClass, the API currently returns an unclear schema validation error. The actual problem is that the VM class cannot be defaulted.

After this change, users get a direct explanation: either set spec.virtualMachineClassName explicitly or mark one VirtualMachineClass as default with the virtualmachineclass.virtualization.deckhouse.io/is-default-class=true annotation.

What is the expected result?

Apply a VirtualMachine manifest without spec.virtualMachineClassName in a cluster where no VirtualMachineClass has the default annotation.

The request should be rejected by the webhook with a clear error explaining that no default VirtualMachineClass is configured and how to fix it.

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: vm
type: fix
summary: "VirtualMachine creation without an explicit VM class now reports a clear error when no default VirtualMachineClass is configured."