over-eager to destroy VM when device start() fails

device start is a fallible operation! we try to start devices in propolis-server:

https://github.com/oxidecomputer/propolis/blob/fcf37aefdc1d3bcce3cbf7e2b984e05ccfe6b553/bin/propolis-server/src/lib/vm/state_driver.rs#L596-L609

if a device fails to start (or a block backend, below, fails to start), we'll then return VmStartOutcome::Failed and eventually eventually get to HandleEventOutcome::Exit. then we set_rundown() and drop the StateDriver, eventually getting through

https://github.com/oxidecomputer/propolis/blob/fcf37aefdc1d3bcce3cbf7e2b984e05ccfe6b553/bin/propolis-server/src/lib/vm/objects.rs#L420-L433

at this point we'll have dropped the Machine, uninstalled the guest's memory (and MSI-X handle!) from devices, and dropped everything. some devices will have been started, some will not yet have started. devices that have started will have some parts dropped by Propolis, but spawned threads and spawned tasks may not be cancelled, stopped, joined on, etc.

#1110 is, in part, because the vsock poller expects that once it has memory, memory only goes away after the device is paused and the poller thread is told to exit. we probably should expect that Propolis embedders follow the valid state transitions described by Indicator, and that if a device is started it must be paused before dropping the Machine, that a device is halted when dropped, etc.

Trace the failed-start path in bin/propolis-server/src/lib/vm/state_driver.rs, including set_rundown(), then inspect Machine cleanup in bin/propolis-server/src/lib/vm/objects.rs. Read the valid lifecycle transitions in lib/propolis/src/lifecycle.rs and compare them with the device-start failure path. Done means started devices are paused or halted and their spawned work is stopped before the Machine and guest memory are dropped.