PHD FAT volumes aren't recognized by WS2022's in-box FAT driver

Repro steps: create a PHD VM with a virtio disk backed by a PHD FatFilesystem and run a test with a Windows Server 2022 guest.

Expected: The guest recognizes the disk's partition/volume structure and allows a drive letter to be assigned to the file system.

Observed: The guest recognizes the physical disk, but believes it has no partitions or volumes and doesn't allow it to be mounted.

This is annoying because it prevents tests from working with files on an in-memory disk using native OS file system APIs. Because the data on the disk is not recognized at all, it's not possible to use Powershell cmdlets or a diskpart script as a workaround, at least as far as I can tell. I believe it's still possible to muck around with the physical blocks on the disk from Cygwin with utilities like dd, though, if you specify something like \\.\PhysicalDrive1 as the relevant file path.

This doesn't affect cloud-init drives that are parsed by cloudbase-init (the cloud-init provider we recommend in the image builder) because it uses tools from the GNU Mtools suite to read the cloud-init drive's contents at the physical disk layer (i.e. it uses a tool in the suite to copy files from a VFAT cloud-init drive without using any OS filesystem drivers).

I have not tested this with other flavors of Windows but I imagine they'll have the same problem.

Start with the PHD FatFilesystem implementation in phd-tests/framework/src/disk/fat.rs, then reproduce the issue with a virtio disk and a Windows Server 2022 guest. Investigate why the guest sees the physical disk but not its partitions or volumes. Done means the in-box FAT driver recognizes the volume and allows a drive letter to be assigned.