Live migration of microVMs

Nobody has claimed this yet.

## Goal

Move a running microVM from one host to another without recreating it from spec.

## Context

Today identity is pass-through: Brigade stores flintlock's uid keyed to a host. Migration requires the VM's identity to survive a host change, which is why the design keeps `uid` wrapped in the VM record so a **Brigade-owned uid** can be introduced later (external handle stable across host moves, internal flintlock uid diverges).

## Dependencies / unknowns

- flintlock support for state/memory transfer (firecracker/cloud-hypervisor snapshot + restore) — needs investigation; may not exist.
- Brigade-owned uid indirection (record already structured for it).
- Coordination: reserve on target, transfer, cut over, release source — a multi-phase state machine with fencing to avoid double-run.

Large, depends on upstream capabilities. Deferred from the M0–M4 build.

Start by investigating whether Flintlock supports Firecracker or Cloud Hypervisor snapshot and restore for state and memory transfer. Then read the VM record's uid structure and map the reserve, transfer, cutover, fencing, and source-release phases described in the issue. Done means a design and implementation that preserves Brigade-owned identity without allowing the microVM to run on both hosts.

Written by the indexing model from the issue text.