Virtualization.framework: supported VM lifetime and terminal-state proof after owning-process death

We are evaluating Virtualization.framework for a disposable, offline synthetic Linux test VM on Apple silicon (observed host: macOS 26.5.1, build 25F80, arm64).

The VM has no network devices, host directory shares or host-execution sockets. Normal guest shutdown and VZVirtualMachine.stop(completionHandler:) have been exercised with the owning process alive. We have not injected owning-process death.

Apple's GUI Linux sample documentation says the VM continues until guest shutdown or app quit. The stop API documents successful completion or error through the owning VM object. We need to distinguish those normal paths from abrupt loss of the process that actually owns that object—not just termination of an outer controller.

Could you clarify the supported contract for these cases?

1. If the owning process crashes or is terminated with SIGKILL, is the associated VM guaranteed to stop executing? If so, what public contract specifies the applicable macOS versions, completion semantics and any bounded shutdown deadline? Does this require application cleanup code or retention of another client?

2. Can a separate surviving process use a supported public API to identify the exact previously running VM and obtain terminal-state proof after the owner is gone? Is there a supported adopt/query/stop mechanism, or is there intentionally no such cross-process interface?

3. If automatic teardown is guaranteed, what supported observation establishes that this specific VM can no longer execute or initiate I/O before its task-owned backing resources are removed? An accepted stop request or disappearance of an app PID would not by itself establish that condition for our test controller.

4. If no such contract or observation exists, is the supported design to retain a live owner and treat unexpected owner loss as an unresolved state requiring a different recovery boundary? Please distinguish documented guarantees from current implementation behavior, including behavior when the virtualization backend itself fails or becomes unresponsive.

We are asking about lifecycle containment, not graceful guest filesystem shutdown, saved-state restoration into a new VM, or serializable guest hardware identity. References to the appropriate public documentation would be helpful.