Well this seems to be a little more complex than I first thought and appears to relate to a behaviour triggered in Hyper-V and not VMM specifically.
After much digging through the VMM debug log, I can see that a WMI query to Msvm_ImageManagementService.GetVirtualHardDiskState is failing due to error 2147942570 (which is 0x800700AA). I can reproduce this manually using WMI on any VHD attached to the affected VM. Queriying the VHDs attached to other VMs on the same hypervisor works fine.
This WMI provider is implemented by the Hyper-V management process vmms. Restarting VMMS has no effect. Live migrating or restarting the VM fixes the issue.
Running sysinternals ProcMon tool on VMMS shows that querying for VHDs attached to other VMs on the same hypervisor host works, but for the affected VM a SHARING_VIOLATION is being generated. This matches with the error code being produced at the WMI level. The requested open was for a generic shared read.
As restarting VMMS has no effect, but live migrating/restarting the VM does, I would guess that another process is the culprit. According to sysinternals handle tool, only the VMWP process (Hyper-V process representing the VM) and the SYSTEM process have file handles open to the VHD files. As live migrating/restarting the VM will cause a new VMWP process to be started, it's likely that VMWP is the one preventing shared access - though it could be something funky with how the SYSTEM has the file open as well.
Is there any way to determine what flags were used on open file handles? I'd like to query the handles in the different processes and see what flags each are using to determine which one is the potential culprit.