[lbarrosby]

What this PR does / why we need it:

defaultVMInstanceType ignored the kind of the instancetype matcher and always tried the namespaced VirtualMachineInstancetype first. If a namespaced and a cluster-scoped instance type share a name, a MachineDeployment that explicitly asks for VirtualMachineClusterInstancetype got the namespaced one.

With this change the lookup is limited to the requested kind (singular or plural, case-insensitive, as KubeVirt accepts). When kind is empty the previous order is kept, so existing specs behave the same.

Added TestDefaultVMInstanceType with a fake client holding both kinds under the same name. Three of its cases fail on main and all pass with the fix; go test ./pkg/cloudprovider/provider/kubevirt/ passes.

AI disclosure: written with the help of Claude Code, reviewed and tested by me.

Which issue(s) this PR fixes:
Fixes #2065

What type of PR is this?
/kind bug

Special notes for your reviewer:
An explicit kind that does not exist now returns an error instead of falling back to the other scope, which matches what KubeVirt does when the VM is created.

Does this PR introduce a user-facing change? Then add your Release Note here:

KubeVirt: the instancetype kind set in the provider spec is now honored when a namespaced and a cluster-scoped instance type have the same name.

Documentation:

NONE

[kubermatic-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign adoi for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[kubermatic-bot]

Hi @lbarrosby. Thanks for your PR.

I'm waiting for a kubermatic member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.