migration: refine the pre-install step — no --domain, so no ACME attempts at all

Current Cloudron serves the setup page on the server IP with a self-signed cert and takes the domain in the wizard, so cloudron-setup needs no DNS and, with the domain left unset, makes zero certificate attempts: the rate-limit risk only appears if the domain is entered while DNS still points at Hostinger. Adds the post-install checks (version >= 10.1.5, pristine, no apps) and a VPS snapshot to roll back to.

cloudron-server-migration.md

@@ -69,14 +69,23 @@ needed to restore are inside the thing being restored.
       (`/api/v1/cloudron/status` → `10.1.5`; backup manifests read `box_v10.1.5`). The
       earlier note of "9.0.4" was the *CLI* version, not the platform — a restore cannot go
       backwards.
-- [ ] **Install now, stop before the wizard.** `cloudron-setup --domain my.inference.coop`
+- [ ] **Install now, stop before the wizard.** Run `cloudron-setup` with **no `--domain`**, and leave
-      installs Docker, the platform and the CLI, and needs no DNS of its own — certificate
+      the browser wizard for cutover day. On current Cloudron the setup page is served on the
-      issuance will simply fail and retry until DNS moves (harmless, but it does mean ACME
+      server's **IP with a self-signed certificate**, so the install needs no DNS — and because the
-      attempts against a hostname still pointing at Hostinger; watch Let's Encrypt rate
+      domain is not entered yet it makes **no certificate attempts at all**. The Let's Encrypt
-      limits). **Leave the browser setup wizard for cutover day**: that is where the
+      rate-limit risk noted earlier only materialises if you enter `my.inference.coop` while DNS still
-      restore-from-backup and the subscription/plan are chosen, and completing it early
+      points at Hostinger; leaving it unset means the box sits idle and retries nothing, so it needs
-      risks moving the subscription off the live server. Verify that risk before touching
+      no powering off. This de-risks the one step that can hard-fail (kernel, Docker, OS support)
-      the wizard — it is the one step worth reading twice.
+      while there is still time to act on it.
+      **Check immediately after installing:** `cloudron --version` ≥ **10.1.5** (a restore cannot go
+      backwards — 10.1.5 is the platform version this box runs; the earlier note of "9.0.4" was the
+      *CLI* version), `cloudron status` healthy, Docker running, and **no apps installed** (a pristine
+      platform is what a restore expects).
+      **Leave for cutover day:** the domain, the plan/subscription (completing the wizard early can
+      move the subscription off the live server — the one step worth reading twice), and the
+      restore-from-backup itself.
+- [ ] Take an Infomaniak **snapshot of the VPS right after the install** (snapshots: 0 of 1 used), so a
+      botched wizard on cutover day can roll back to a known-good installed platform.
 - [ ] Confirm the Cloudron subscription can be moved to a new server (do it at cutover,
       not early).
 - [ ] **IPv6: DECIDED — repoint.** The new box has `2001:1600:18:206::89`, so all 18