docs: README and doc/ match the code

- Deleting VMs and moving disks are jobs too (Features, Behavior
  changes, architecture), and the API's delete answers 202.
- Docker keeps the TLS client certificates in webvirtcloud-pki.
- The manual installation covers Ubuntu 26.04 and Debian 13, says lxml
  is reused like libvirt-python, and adds the service user to the
  libvirt and kvm groups, as the installer does, for a socket compute.
- Moving to a new machine starts in the clone's directory (Docker) and
  copies secret_key only when the backup has it (installer); the
  off-site steps run in the panel's checkout; an update's backup also
  holds /etc/default/webvirtcloud and local-migrations.tar.
- A kept settings.py is rebuilt from the template instead of patched by
  a list that had fallen behind (knox, axes, four middlewares).
- gstfsd on 127.0.0.1 serves a panel that adds its compute as localhost;
  LOGIN_TRUSTED_PROXIES matters only for a proxy on another machine;
  socket computes reach a localhost console too.
- New passwords pass Django's validators (Behavior changes).
- permissions: a VM an administrator paused stays paused for owners.
- architecture: nginx listens on 80, on 443 only with your TLS.
- Running tests: the libvirt layer's tests are in vrtManager/tests.

doc/architecture.md

@@ -18,7 +18,7 @@ WebVirtCloud is a web panel for libvirt hosts. libvirt is the source of truth: t
 ## Processes
 
 ```
-browser ── nginx :80/:443
+browser ── nginx :80 (:443 with your TLS)
              ├── /            → gunicorn 127.0.0.1:8000 (Django)
              ├── /static/     → staticfiles/
              ├── /novncd/     → novncd 127.0.0.1:6080 (VNC console, websockify)
@@ -72,7 +72,7 @@ The libvirt layer: the connections and the host objects the apps work on (the ap
 
 ## Jobs
 
-Long operations (create, clone and migrate VMs, clone volumes, snapshots, ISO uploads) are `Operation` rows. The worker claims queued jobs and runs them on a thread pool; an ISO upload runs in the web request and is only tracked.
+Long operations (create, clone, migrate and delete VMs, move disks, clone volumes, snapshots, ISO uploads) are `Operation` rows. The worker claims queued jobs and runs them on a thread pool; an ISO upload runs in the web request and is only tracked.
 
 - **Claims:** a job holds claims on what it changes (VM, volume, pool, name, quota); a conflicting request is refused at once.
 - **Recovery:** a job whose worker died is never run again. The new worker reads what happened from libvirt and ends it as succeeded, failed or uncertain; an uncertain job keeps its claims until a superuser resolves it.
@@ -87,4 +87,4 @@ Long operations (create, clone and migrate VMs, clone volumes, snapshots, ISO up
 - `instances/`, `flavor/`, `migrate/`, `operations/`
 - schema at `/api/schema/`, Swagger at `/swagger/`, ReDoc at `/redoc/`
 
-Create and migrate answer 202 with the job.
+Create, migrate and delete answer 202 with the job.

doc/permissions.md

@@ -28,5 +28,6 @@ Notes:
 
 - Only superusers choose disk names and MAC addresses when cloning; for other users the server derives them.
 - `is_staff` gives no access to VMs and does not reveal console settings or VNC passwords by itself.
+- A VM an administrator paused stays paused for its owners: their power actions on it are refused.
 - A template VM is changed (resize, root password, SSH keys, options, console settings, snapshots) only by superusers and by staff owners with `is_change`, and deleted only by superusers and staff owners with `is_delete`; other owners keep view, console and power (power on and power cycle of a template are refused with a warning). Cloning a template needs only view access and `instances.clone_instances`.
 - On VM pages, users without ownership or `view_instances` get **404** (the VM's existence is not revealed), and users who can see a VM but lack the right for an action get **403**. Superuser-only pages answer **403** to everyone else; the console page answers **403** both for a missing VM and for a VM the user may not open.