Supported backing-file release semantics after stopping a Virtualization VM

I am designing a macOS Virtualization application using RAW disk images, an EFI variable store and host directory sharing. I need to distinguish stopping guest execution from releasing host backing-file access.

I inspected the public declarations for VZDiskImageStorageDeviceAttachment, VZEFIVariableStore, VZSharedDirectory and VZVirtualMachine in the macOS27 SDK. The stop completion describes a stopped VM or an error; the backing types expose URL-based initialization. I could not identify a final backing-release event in those declarations. I would appreciate the supported contract, including any differences on macOS26 and macOS27.

For each of the three URL-backed surfaces:

1. When are paths resolved and backing references opened? Can the framework reopen a path or lazily access shared descendants later?
2. Does successful stop completion guarantee backing references are released and required writes persisted, or only that guest execution stopped?
3. What object-reference release and queue/callback ordering is required before the application may safely reuse, replace or remove the backing objects?
4. Can Virtualization helper processes retain backing access after the application's worker process exits? Is there a supported observable event covering those references?
5. If no such release event is documented, what supported architecture should retain or quarantine these resources until release can be established?

I am not using physical block devices and am not generalizing their documented file-handle retention to URL-backed images, EFI stores or directory shares. Please link the public contract or clarify which behaviors are unspecified.