fix(vi): unpacked size

[danilrwx]

Description

Fix unpacked size detection for VirtualImage and ClusterVirtualImage created from VirtualDiskSnapshot via PVC.

The change updates the PVC-backed VirtualImage ready flow to use the requested PVC size as the unpacked size instead of the bound PVC capacity. This avoids reporting inflated unpacked size when the storage backend rounds PVC capacity up.

Also added unit tests for:

• unpacked size selection logic for PVC-backed snapshot refs;
• size propagation from VirtualImage to ClusterVirtualImage.

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

When a VirtualImage is created from VirtualDiskSnapshot on PVC storage, the controller previously used pvc.status.capacity for both stored and unpacked size.

On some storage backends, status.capacity can be greater than the requested restore size. As a result, .status.size.unpacked was reported incorrectly for VirtualImage and then propagated further to ClusterVirtualImage.

This change makes unpacked size reflect the requested PVC size, which matches the logical image size and prevents incorrect size reporting in VI/CVI status.

What is the expected result?

1. Create a VirtualImage from VirtualDiskSnapshot using PVC storage.
2. Use a case where PVC capacity is larger than the requested restore size.
3. Verify that:
   • status.size.stored matches the actual PVC capacity;
   • status.size.unpacked matches the requested PVC size;
   • ClusterVirtualImage created from that VirtualImage preserves the same unpacked size.

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: core
type: fix
summary: "Fix unpacked size reporting for VI/CVI created from VirtualDiskSnapshot via PVC."
impact_level: low