Windows: report free space of the volume backing the VM data directory

[adihanifsdr]

Problem

On Windows, the New Sandbox dialog (Free: N GB | VMs allocated: ...) and the headless /host endpoint (freeGb) compute free space from the %ProgramData% root. VMs are actually stored under %ProgramData%\AppSandbox.

Users with a small C: commonly redirect that directory to another drive with a junction (mklink /J C:\ProgramData\AppSandbox D:\AppSandboxData). VHDX files then land on D:, but the UI keeps showing the free space of C:, which is misleading when sizing a new sandbox.

Before (VM storage junctioned to D:, 155 GB free):

Path queried	Reported free
C:\ProgramData (current code)	11 GB
C:\ProgramData\AppSandbox (this PR)	155 GB
D:\	155 GB

Change

• src/app_win/ui.c (build_host_info_json) and src/app_win/headless.c (build_host_info): query %ProgramData%\AppSandbox so GetDiskFreeSpaceExW resolves the reparse point, and fall back to the %ProgramData% root when the directory does not exist yet (fresh install).
• Also aligns the headless fallback path with ui.c (C:\ProgramData instead of C:\).

This matches the macOS backend, whose HostInfo.freeGb already reports "free bytes on the volume that backs the VMs root directory".

Testing

• Built AppSandbox.sln Release|x64 with MSBuild (VS 2026 Community); compiles clean apart from the pre-existing DwmSetWindowAttribute warning in vm_display_idd.c.
• Verified with a P/Invoke call to GetDiskFreeSpaceExW on a host where C:\ProgramData\AppSandbox is a junction to D: (table above).
• No behaviour change on a default install (no junction): the leaf directory is on the same volume as the root.

🤖 Generated with Claude Code

[adihanifsdr]

@jamesstringer90 heads-up on this one when you have a moment — small Windows-only fix so the "Free: N GB" figure in New Sandbox (and freeGb in the headless API) reflects the drive that actually holds the VHDX files when %ProgramData%\AppSandbox is junctioned to another disk. Builds clean on Release|x64. Thanks!