feat(kubevirt): add pause/unpause support to vm_lifecycle tool

[lyarwood]

Summary

The vm_lifecycle tool currently supports start, stop, and restart actions but not pause or unpause. KubeVirt's pause/unpause functionality freezes a running VMI in place (preserving memory/CPU state), which is distinct from stop (which shuts down the VM entirely).

Problem

The KubeVirt pause/unpause API uses the subresources.kubevirt.io API group rather than the main kubevirt.io group:

PUT /apis/subresources.kubevirt.io/v1/namespaces/{ns}/virtualmachineinstances/{name}/pause
PUT /apis/subresources.kubevirt.io/v1/namespaces/{ns}/virtualmachineinstances/{name}/unpause

The AccessControlRoundTripper in pkg/kubernetes/accesscontrol_round_tripper.go validates all outgoing requests against the REST mapper. Since subresources.kubevirt.io is a virtual API group that doesn't appear in standard API discovery, the round tripper rejects requests to it with:

Validation Error [RESOURCE_NOT_FOUND]: Resource virtualmachineinstances.subresources.kubevirt.io does not exist in the cluster

This blocks the dynamic client from reaching the pause/unpause endpoints, even though the endpoints exist and work when called directly (e.g. via kubectl proxy).

Possible approaches

1. Allowlist subresources.kubevirt.io in the AccessControlRoundTripper -- skip REST mapper validation for known KubeVirt subresource API groups
2. Bypass the round tripper for subresource calls -- use a separate HTTP client/REST client that doesn't go through the access control layer
3. Use the KubeVirt client library directly -- import kubevirt.io/client-go and use its typed client for pause/unpause

Context

The pause-vm eval task was removed in #1054 because the tool doesn't support pause. Once this is implemented, the eval task should be re-added.

/cc @ksimon1

[lyarwood]

See #884 for an earlier attempt at this.

[Knickkennedy]

I'm trying to contribute and I was going through 884 and now 1061 and I was wondering something. Is it sort of like the only two options are to skip the mapper, or to use the kubevirt.io/client-go package directly? The first option feels like a security concern, but I am not a contributor.