fix(lcow/v2): report physically backed VM stats

[shreyanshjain7174]

Summary

• derive LCOW V2 SandboxOptions.FullyPhysicallyBacked from the final VM memory configuration (!Memory.AllowOvercommit)
• avoid looking up a vmmem process for physically backed UVMs; their working set comes from HCS AssignedMemory
• add focused builder and parity coverage for the memory-backing decision

This includes Harsh's 47c5b143 patch, cherry-picked as e3e4cfb6, together with the complementary vm.go lookup gating.

Problem

LCOW V2 physically backed sandbox stats had two related failure modes:

1. setting AllowOvercommit=false without the stronger FullyPhysicallyBacked annotation left SandboxOptions.FullyPhysicallyBacked false, so the controller selected the VA-backed stats path for physically backed VM memory;
2. Stats() looked up vmmem before checking the backing mode, even though physically backed UVMs use HCS AssignedMemory. A failed lookup therefore prevented metrics that do not require vmmem.

Implementation

• parse the FullyPhysicallyBacked annotation separately for device-backing behavior and its existing overcommit override
• set SandboxOptions.FullyPhysicallyBacked from the finalized memory configuration
• move LookupVMMEM and process working-set collection inside the VA-backed branch
• update parity expectations and cover AllowOvercommit=false without the annotation

Validation

• go test -tags lcow ./internal/builder/vm/lcow/... ./internal/controller/vm/... -count=1
• go vet -tags lcow ./internal/builder/vm/lcow/... ./internal/controller/vm/...
• rebuilt containerd-shim-lcow-v2.exe with both changes and ran Test_SandboxStats_WorkingSet_PhysicallyBacked/LCOW against a local build 26200 host: PASS
• restored the original deployed shim after the functional run and verified its SHA-256 and the running containerd service

[rawahars]

This PR can be superseded by 47c5b14 which correctly sets the param in SandboxOptions which in turn calculates the stats properly.

[shreyanshjain7174]

Thanks, Harsh. Does 47c5b143 also address the unconditional LookupVMMEM call in Stats()? If not, should this PR keep only that gating change and let your commit own the flag derivation?

[rawahars]

@shreyanshjain7174 Yes let's keep your changes in vm.go which move vmmem lookup inside the if check.