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>

storages/tests/test_upload_job.py

@@ -303,7 +303,9 @@ class LocalUploadTests(LocalPool, UploadTestCase):
 
     def test_ending_without_the_compute(self):
         op = self.send(0, b"aaa")
-        self.compute.delete()
+        with self.assertRaises(claims.Busy):  # the upload holds the compute
+            self.compute.delete()
+        Compute.objects.filter(pk=self.compute.pk).delete()  # the row gone without Compute.delete()
         op = jobs.cancel(op.pk, self.admin)
         self.assertEqual((op.state, op.error), (Operation.FAILED, "The compute was deleted"))