destroy_virtual_hardware.sh does not notice when it fails to delete zpools

+ for ZPOOL in "${ZPOOLS[@]}"
+ VDEV_FILE=/home/dap/omicron/oxi_b462a7f7-b628-40fe-80ff-4e4189e2d62b.vdev
+ zfs destroy -r oxi_b462a7f7-b628-40fe-80ff-4e4189e2d62b
+ zfs unmount oxi_b462a7f7-b628-40fe-80ff-4e4189e2d62b
cannot unmount 'oxi_b462a7f7-b628-40fe-80ff-4e4189e2d62b': not currently mounted
+ warn 'Failed to remove ZFS pool and vdev: oxi_b462a7f7-b628-40fe-80ff-4e4189e2d62b'
+ set +x
Failed to remove ZFS pool and vdev: oxi_b462a7f7-b628-40fe-80ff-4e4189e2d62b
+ success 'Verified ZFS pool and vdev oxi_b462a7f7-b628-40fe-80ff-4e4189e2d62b does not exist'
+ set +x
Verified ZFS pool and vdev oxi_b462a7f7-b628-40fe-80ff-4e4189e2d62b does not exist

In this case, it failed to remove the zpool (it wasn't mounted, probably because I'd rebooted the system?), but proceeded anyway. I believe the exit code was 0.

Here's the code:
https://github.com/oxidecomputer/omicron/blob/ebd3db27f6bbd08af3194cae84b0efc6b6e7248d/tools/destroy_virtual_hardware.sh#L110-L114

I guess it's maybe intentional that this was only a warning? I think it's misleading though. It took a few setup laps before I noticed the zpools weren't getting recreated.

Open tools/destroy_virtual_hardware.sh at lines 110-114 and trace the zpool deletion and verification path shown in the report. Reproduce the unmount or deletion failure case, then confirm the script returns a failure rather than reporting success when cleanup was not completed.