migration: resolve OS support, correct the version floor, split install from wizard

Ubuntu 26.04 LTS is supported (docs) and the real version floor is the
PLATFORM version 10.1.5, not the CLI's 9.0.4. Provider firewall is not
Cloudron's job (80/443 dropped, 22 open), rDNS belongs to Infomaniak, and
the setup wizard is where the subscription/restore happen - so install now,
stop before the wizard.

cloudron-server-migration.md

@@ -55,10 +55,23 @@ needed to restore are inside the thing being restored.
       key; if not, retrieve it from the Infomaniak console.
 - [x] New host capacity: **4 CPU, 12 GB RAM, 250 GB disk** (given 2026-10-30) — ample for
       ~6 GB of app data plus images. Old box used ~17 GB of 58 GB.
-- [ ] OS: the new box is **Ubuntu 26.04 LTS**. Confirm Cloudron 9.x supports 26.04 *before*
+- [x] OS: **Ubuntu 26.04 LTS is supported** — Cloudron's install docs specify a fresh
-      installing — an unsupported release can be refused by the installer. Install version
+      Ubuntu 26.04 x64 server. Minimums are 2 GB RAM / 20 GB disk; the new box has
-      must be ≥ the old box's (9.0.4).
+      12 GB / 250 GB. Resolved 2026-10-30.
-- [ ] Confirm the Cloudron subscription can be moved to a new server.
+- [ ] **Version floor: install Cloudron ≥ 10.1.5**, the platform version this box runs
+      (`/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`
+      installs Docker, the platform and the CLI, and needs no DNS of its own — certificate
+      issuance will simply fail and retry until DNS moves (harmless, but it does mean ACME
+      attempts against a hostname still pointing at Hostinger; watch Let's Encrypt rate
+      limits). **Leave the browser setup wizard for cutover day**: that is where the
+      restore-from-backup and the subscription/plan are chosen, and completing it early
+      risks moving the subscription off the live server. Verify that risk before touching
+      the wizard — it is the one step worth reading twice.
+- [ ] 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
       AAAA records move with the A records (§3 originally left this open). The zone carries
       **AAAA records on 18 hostnames** — everything that has an A record — all pointing to
@@ -68,10 +81,15 @@ needed to restore are inside the thing being restored.
       the A records leaves every IPv6-capable client — including other Matrix
       homeservers and mail senders — still reaching the old box.
 - [ ] Set **rDNS/PTR → `my.inference.coop` on BOTH `179.237.86.116` and
-      `2001:1600:18:206::89`**. The console lists reverse DNS as unconfigured for both.
+      `2001:1600:18:206::89`**. Cloudron cannot do this — PTR belongs to the IP owner and
+      exists only in the Infomaniak console. The console lists reverse DNS as unconfigured for both.
       Not time-sensitive — do it now. If IPv6 sending causes trouble later, disable v6
       egress for SMTP rather than removing the AAAA.
-- [ ] Open on the new box: **22, 80, 443, 465, 587, 993, and 25 inbound** (mail delivery
+- [ ] **Open these in the INFOMANIAK console, not on the host** (measured 2026-10-30: 22
+      answers, 80/443 are silently dropped — a provider firewall default). Cloudron manages
+      the host's own iptables but explicitly does not touch the provider firewall: its docs
+      say "ensure the firewall does not block port 80 (HTTP) and 443 (HTTPS)". Ports:
+      **22, 80, 443, 465, 587, 993, and 25 inbound** (mail delivery
       — test from outside, e.g. `telnet my.inference.coop 25` once DNS moves; note that
       many networks block *outbound* 25, so a closed result from inside another server is
       not conclusive). **8448 is intentionally closed** — federation is delegated to
@@ -92,6 +110,8 @@ needed to restore are inside the thing being restored.
       **RESOLVED 2026-10-30:** the host mount is Nextcloud's `/var/lib/nextcloud`, **3 MB**,
       holding only `preview/` (regenerable thumbnails) — not a data-loss risk. Re-run this
       audit only if apps change before the cutover; it is now a confirm, not an unknown.
+- [ ] Leave the **single snapshot slot free** for a post-restore, pre-DNS-switch snapshot —
+      a bad restore then becomes a revert instead of a rebuild.
 - [ ] Record the highest backup run number before the freeze. (As of 2026-10-30 the
       newest run is healthy at ~4.6 GB and the backup space was enlarged, so the quota
       pressure that produced the `EntityTooLarge` failures is relieved — but run growth