Crucible backend should call `deactivate` when pausing during migration

Cleanly deactivating a volume on the source reduces the chance that the volume will need to be repaired when starting the target. This is possibly important for migration performance, though we haven't measured and don't know how often repair will occur during migration or how expensive these repairs will be.

One major challenge with this is that if the source pauses and deactivates, and migration fails, the source (presumably) needs to present a new Crucible generation number in order to activate again. This is somewhat at odds with Omicron's laissez-faire approach to coordinating migrations. Nexus generally hopes to be able to kick off a migration and end up with either the source or target running the VM with no further intervention required. Reactivating, however, requires Nexus intervention, because Nexus is the keeper of Crucible generation numbers and needs to be told to increment them before a migration source can reactivate.

No files, tests, or concrete entry points are named. Start by locating the Crucible migration pause path and how source deactivation is handled, then determine how a failed migration would coordinate a new generation number before reactivation. Done requires resolving the Nexus coordination approach as well as implementing and testing the behavior.