Supported VZ VM termination after owner crash or permanent stall

I am evaluating a disposable Linux VM for bounded local test execution on an Apple Silicon Mac running macOS 15.7.9. Before integrating it, I need to establish the supported VM lifetime and termination-observation contract when its native owner fails.

The synthetic configuration is intentionally small: VZLinuxBootLoader, two vCPUs, 512 MiB RAM, one serial port, and no storage, network, shared directories or socket devices. The native owner creates the VZVirtualMachine and invokes the forced stop(completionHandler:) API on its designated queue.

With that owner alive and responsive, our recorded checks obtain a successful stop completion and the stopped state on the original VM object. We have also checked controller/watchdog/collector loss and a fixed, recoverable owner-queue delay. Those checks do not cover actual native-owner death or a permanent stall.

The intended failure behavior is to reject all candidate output and block further attempts whenever termination is unconfirmed. We also need a supported way to end the original VM's execution; simply retaining a blocked record is not a termination mechanism.

Could you clarify these points for macOS 15.7.9, including any minimum-version differences?

1. If the process that created a VZVirtualMachine crashes or is forcibly terminated, what public contract covers cessation of every associated vCPU and any out-of-process VM/device execution? Is teardown guaranteed, and what can another trusted process observe to confirm completion for that exact VM?
2. If that owner remains alive but is permanently suspended, deadlocked or cannot service its VZ queue, is there a supported external operation to stop that exact VM and receive an authoritative completion result? What privileges or entitlements are required?
3. Would hosting the owner in an XPC service provide a supported VM-level lifetime guarantee when the initiating app exits? How would a surviving or later controller establish the same VM's terminal state? I understand that service termination by itself may be a different observation from VM teardown.
4. If Virtualization.framework cannot provide this contract, does direct Hypervisor.framework document abrupt host-task teardown of every associated vCPU/VM and a supported external completion observation? Process/thread resource mapping alone leaves that question unresolved for this design.

For context, the Apple DTS answer at https://developer.apple.com/forums/thread/845944 distinguishes XPC service lifetime from LaunchAgent lifetime and explains the absence of a launchd wall-clock limit. I am asking specifically about the VM lifetime and observable completion condition, rather than adding another application timer.

We do not treat PID disappearance, successful signal delivery, guest silence, journal EOF, or the initial stopped state of a new VM object as proof that the original VM has ended. We have not run a real owner-kill experiment while the recovery and observation contract is unresolved.

A reference to the supported API/OS guarantee, or confirmation that this combination is not supported, would help us choose the architecture. This is a contract question, not a report of a demonstrated Apple VM teardown bug.