fix: quote the ISO path, bound the wait for a guest IP, and explain bad host output

[tas50]

Three bugs found while sweeping the driver and support/hyperv.ps1. Each one is independent, but they are all small and each comes with the test that would have caught it, so they are together rather than in three near-empty PRs.

An ISO path containing a space never mounted

mount_vm_iso interpolated config[:iso_path] into the generated PowerShell unquoted:

mount-vmiso -id "vm-0001" -Path C:\ISO Files\tools.iso

PowerShell splits that into two arguments, binds C:\ISO to -Path, and then fails on the stray Files\tools.iso. Every other path the driver emits is quoted — New-DifferencingDisk, New-VHD, Resize-VHD, New-KitchenVM — so this was simply a miss. C:\ISO Files\... and C:\Program Files\... are entirely normal places to keep install media.

Get-VmDetail waited forever for an IP address

do { Start-Sleep -Seconds 1 } while (-not (Get-VmIP $vm))

No bound, no output. A VM that boots but never gets an address — no DHCP on the switch, adapter not connected, guest network stack down — leaves kitchen create hanging silently until the user gives up and kills it. There was a @todo on vm_details_ps noting exactly this.

It now stops after ten minutes and says which VM never answered and what to check:

Timed out after 600 seconds waiting for virtual machine 'default-ubuntu-2204' to report an IP address. Check that the VM booted and that its network adapter is connected to a switch with DHCP.

The bound is a -TimeoutSeconds parameter, so it stays adjustable from PowerShell.

The same change stops the function calling Get-VmIP a second time after the wait already found an address. Get-VmIP opens with Start-Sleep -Seconds 10, so every successful create paid an extra ten seconds for an address it was already holding — and because the second call re-reads $vm.networkadapters.ipaddresses, it could return a different adapter's address than the one that ended the wait.

Non-JSON output from the host produced an unusable error

execute_command handed whatever came back straight to JSON.parse. When the host wrote something that was not JSON — a PowerShell warning, a truncated transport read — the user got:

unexpected token at 'WARNING: the RPC server is unavailable'

or worse, an offset into a string they never see. It now raises with the host's actual output included, which is the only thing that makes the failure diagnosable.

Verification

$ bundle exec rake test
122 examples, 0 failures

$ bundle exec cookstyle --chefstyle
12 files inspected, no offenses detected

$ bundle exec rake pester
Tests Passed: 49, Failed: 0, Skipped: 0