fix(computes): a deleted compute's VMs keep their owners

Deleting a compute removed its VMs from the panel together with their
owners, while the VMs kept running on the host: added again, the host's
VMs came back with no owners. A compute's delete now treats each VM as
one that left its compute: its owners follow the same UUID on another
compute or wait in a tombstone for the retention period. One function,
forget(), does this for the refresh and for the delete; the API's
compute delete goes through the same model delete.

The delete holds the compute exclusive and locks its row before its
VMs', as the reconcile does: a reconcile, VM operation or job on the
compute makes it busy instead of losing owners to a concurrent restore
or deadlocking with it.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

computes/models.py

@@ -1,5 +1,6 @@
 from ipaddress import ip_address
 
+from django.db import transaction
 from django.db.models import CharField, IntegerField, Model
 from django.utils.functional import cached_property
 from django.utils.translation import gettext_lazy as _
@@ -88,3 +89,17 @@ class Compute(Model):
 
     def __str__(self):
         return self.name
+
+    def delete(self, *args, **kwargs):
+        """Its VMs keep running on the host: their owners wait in tombstones,
+        or follow a VM already listed on another compute. The compute is held
+        exclusive, so no reconcile, VM operation or job on it runs meanwhile
+        (Busy if one does); its row is locked before its VMs', as the
+        reconcile does."""
+        from computes.utils import forget, libvirt_compute_lock
+
+        with libvirt_compute_lock(self), transaction.atomic():
+            Compute.objects.select_for_update().filter(pk=self.pk).first()
+            for inst in self.instance_set.select_for_update():
+                forget(inst)
+            return super().delete(*args, **kwargs)