`unencrypted_vms` test runs concurrently with github runner E2E tests.
If the `verify_host_capacity` step overlaps with github runner VMs being
destroyed, then there's a race condition that host's capacity has been
updated in `Nexus::destroy` but Vm's record hasn't been deleted yet,
which happens in a following `Nexus::destroy_slice` label.
An example of such failure was:
https://github.com/ubicloud/ubicloud/actions/runs/13269484154/job/37045283146
In this failure, sequence of events that caused the problem were:
```
{"runner_allocated":{... "vm_ubid":"vmm5zmzc4qst7qx1h9gjahnk9x" ...}}
{"strand_hopped":{"from":"Vm::Nexus.wait","to":"Vm::Nexus.destroy"},"thread":"vmm5zmzc4qst7qx1h9gjahnk9x"}
{"strand_hopped":{"from":"Test::VmGroup.wait_verify_vms","to":"Test::VmGroup.verify_host_capacity"}}
{"strand_hopped":{"from":"Test::VmGroup.verify_host_capacity","to":"Test::VmGroup.failed"}}
{"strand_hopped":{"from":"Vm::Nexus.destroy","to":"Vm::Nexus.destroy_slice"},"thread":"vmm5zmzc4qst7qx1h9gjahnk9x"}
```
To avoid sporadic failure, and given that `verify_host_capacity` is
already exercised in few relevant situations, we disable
`verify_host_capacity` for `unencrypted_vms`.
Also added more details to failure's error message, so we have more data
to look into if this fails again.
eb9aee9e3f