Harden vGPU release ordering in the instance lifecycle

[yummybomb]

Summary

Layer 2 of the vendor VFIO vGPU stack (#366 ← this ← #363 ← #364 ← #321). Where #366 is a behavior-preserving refactor, this layer changes lifecycle semantics — release ordering and retention — still on mdev-era machinery, before the vendor VFIO backend lands above:

• Delete releases the vGPU before other teardown — a successful release persists the cleared assignment before later teardown. A failed release keeps the pre-refactor contract: it is logged and the delete continues, since the release guards never destroy a device they cannot prove is unowned and a skipped release is recovered by startup reconciliation. Stopped instances retry a previously failed release.
• Stop keeps its no-op contract — a failed retained-release on stop logs and retains the assignment metadata instead of failing the stop; assignments are passed to DestroyVGPU as a struct.
• Forks don't inherit retained assignments — a retained (failed-release) vGPU assignment is stripped from fork metadata so a fork can't release its parent's device.
• Start persists a stale release immediately — releasing a stale assignment before start writes the cleared metadata at once, so a later start failure can't leave metadata pointing at a device that's already gone.

Testing

• go build ./..., go vet clean
• go test -race targeted lib/instances lifecycle suites pass

---

Note

Medium Risk
Changes GPU device teardown and metadata persistence on start/stop/delete/fork. Incorrect ordering could leak or double-destroy vGPUs, but failed releases remain best-effort and are covered by new lifecycle tests.

Overview
Tightens vGPU assignment ownership so a failed release cannot leak a device to another instance or leave stale host paths in metadata.

Stop now retains assignment metadata when destroy fails (instead of clearing it anyway). A later stop of an already-stopped instance retries that release without breaking the no-op contract.

Start releases any retained assignment and persists the cleared fields before recreating a vGPU, so a later start failure cannot point at a device that is already gone.

Delete releases the vGPU immediately after the VMM is dead (before network/device/volume teardown) and persists a successful clear. Failed release still continues teardown. Restart policy is blocked and metadata reloaded first so later saves do not wipe the block.

Fork/restore never share a live assignment: forks strip device path/UUID (profile is kept); snapshot restore keeps the instance’s current assignment instead of resurrecting the snapshot copy.

^{Reviewed by Cursor Bugbot for commit c1048a4. Bugbot is set up for automated code reviews on this repo. Configure here.}

[yummybomb]

Trimmed over-engineering after an architectural review against the parent task (host kernel 6.8 / Ubuntu 24.04 support):

• 1c1f52e — dropped the HasMdev/IsAllocated() compatibility shim. VirtualFunction is internal and never serialized in an API response or persisted, so a single Allocated field is enough.

Kept as-is:

• the delete/stop behavior change (fail and retain assignment metadata when release fails) — orphan reconciliation only runs at startup, so failing the delete is the correct fail-closed behavior;
• the darwin DestroyVGPU unknown-framework error — it keeps the fail-closed rollback semantics identical on macOS, which the lib/instances tests exercise in CI.

Tests: go test -race ./lib/devices, ./lib/resources, ./lib/hypervisor/qemu, ./lib/hypervisor/cloudhypervisor, and the vGPU-targeted ./lib/instances tests all pass; the remaining lib/instances E2E failures require KVM/images and fail identically on an unmodified checkout.