Migration out doesn't destroy the second (and later) VMs to be instantiated in a Propolis process

Repro steps:

1. Create two Propolis processes, A and B
2. Start a VM in A
3. Migrate A -> B -> A -> B

Expected: After the last migration, A's instance state is Destroyed and no bhyve VMM exists for it
Observed: A's instance is Stopped and its bhyve VMM is around. Issuing a "stop" API request to A fails with a "no instance" error. If you migrate B -> A again, A drops the old VMM and creates a new one, but now B is in the stopped-but-not-destroyed state.

This is probably a reference counting bug where creating an instance inside a Propolis that previously had one causes someone to hold on to the new instance's VmController for too long, but does so in such a way that they drop it if a new VM gets created. The TracingArc from #380 might help with this.

Triage: Unscheduled; not needed for MVP because Omicron doesn't reuse Propolis processes in this way.

Trace instance creation and migration lifecycle ownership in Propolis, focusing on how each VmController is retained and released when a process instantiates a later VM. Review the TracingArc work from #380 and reproduce the A → B → A → B sequence. Done means A and B reach Destroyed after migration out, with no lingering bhyve VMM or failed stop request.