Previously, `VmHostSlice.enabled` was overloaded to mean both:
- The slice was prepared
- The slice was not scheduled for destruction
In old times, we waited for slice to be prepared before preparing the VM
inside it. We removed the “prepared” check in 428d367, so tracking
preparedness in a vm_host_slice column is no longer needed. The
“prepared” state can still be inferred from the Strand’s label if
necessary.
A slice is allocatable immediately upon creation (we already allocate
the first VM at creation time). When `slice.is_shared=false`, 2nd
allocation couldn't happen. When `slice.is_shared=true`, we waited until
the slice is prepared to allow the 2nd allocation. This isn't necessary.
The other use of `enabled` is to prevent new VM allocations once a slice
is scheduled for destruction. A slice is marked for destroy when its
last VM begins teardown.
-------------
Dropping the “prepared” purpose of `enabled` clarifies its intent and
fixes an edge case where unprepared slices could be left behind after
their final VM was deleted. Previously, `Nexus::destroy_slice` relied on
an `enabled: true → false` transition that never fired for unprepared
slices, leaving them orphaned. This could happen for example in cases
when a VM was destroyed before its slice was prepared.
Theoretically, there were few other ways to solve this issue. But this
change makes the system less complex in addition to solving the issue.
cbd4c77cdf