Sync the self-hosting stack

CHANGELOG.md

@@ -9,6 +9,40 @@ one of them changed. An entry says which artefact and which version, so `web 0.1
 Every version published to a channel appears here. Nothing is written from memory afterwards: a build
 cannot be published without its entry.
 
+## 2026-10-22 — Cloned machines enroll as separate machines `api 2.1.0` `web 2.1.0` `agent 0.52.0`
+
+**A cloned machine no longer replaces the machine it was cloned from.** Two machines cloned from one
+VM or container template without regenerating `/etc/machine-id` (on Windows, without sysprep) looked
+like one machine to Jarvis: installing the agent on the second took over the first one's agent — its
+key, its asset and its open session. A machine's agent is now identified by its key. Running the
+install command again on a machine still re-enrolls the same agent onto the same asset, and a
+reinstall from scratch is still recognised when the agent it replaces is offline and has the same
+hostname. Any other machine enrolls as a new one with its own asset, and the first is left exactly as
+it was.
+
+**What changes for you**
+
+- **Machines that share a machine ID are marked.** The Agents page and an asset's agent section show
+  **Duplicate ID** on every agent whose machine ID another agent also has, and the tooltip names the
+  others. Give the clone its own machine ID — on Linux, `rm /etc/machine-id && systemd-machine-id-setup`
+  — and run the install command on it again: the mark goes away.
+- **A single-machine install command run on a clone of that asset's machine is refused while the
+  machine is connected**, instead of taking its place. The command keeps its use: give the clone its
+  own machine ID, or stop the agent on the other machine, and run it again. On different hardware it
+  moves the asset as before.
+- **The agent identifies a machine by its machine ID and its hardware UUID.** Agent 0.52.0 adds the
+  SMBIOS system UUID, which hypervisors regenerate when they clone a VM, so cloned VMs no longer share
+  an identity at all. A machine with no readable UUID — most containers — sends what it sent before.
+  Running the install command again after the update re-enrolls the same agent, as always. A
+  reinstall from scratch of a VM that has not re-enrolled since the update enrolls as a new machine:
+  delete the old, offline record on the Agents page.
+- **The database migration is additive.** It turns the unique index on agent fingerprints into a
+  plain one; nothing is dropped, and the api applies it when it starts. Once a clone has enrolled,
+  do not go back to api 2.0.0: its enrollment fails on a fingerprint that two agents share.
+
+Update the API and web images together. Updating the agent release image is recommended; enrolled
+machines take the new build under their update policy.
+
 ## 2026-10-22 — A rebuilt database; 2.0 starts from an empty one `api 2.0.0` `web 2.0.0`
 
 **2.0 does not upgrade a 1.x instance.** Its database schema was rebuilt — table and column names,