migration plan: close the credential items; correct the mail-port claim

Two corrections and one closure. (1) The S3 secretAccessKey is confirmed held externally by the operator, which was the last credential item a restore depends on. (2) The Vault export question is closed: the operator has the passwords outside the server, and the full export stays optional since the vault database rides in the Cloudron backup. (3) The mail ports were listed as "still to confirm" after I reported a timeout as closure. That was wrong for the same reason the earlier port-25 note was: the box has no mail app yet, and Cloudron drops rather than refuses, so a timeout is uninformative. Recorded what is actually known, and the 2026-10-30 IPv6 refusal as the better evidence that those ports are permitted.

cloudron-server-migration.md

@@ -86,7 +86,13 @@ needed to restore are inside the thing being restored.
       `sudo cloudron-support --troubleshoot`. The version needs no guessing: a fresh install pulls the
       current release, which is 10.1.5 or newer, and anything ≥ 10.1.5 restores this backup.
       **Ports on the new box: 25 inbound CONFIRMED OPEN** (operator, via the Infomaniak portal, 2026-11-01 — this is the receive path, and it is the half that cannot be replaced by a relay).
-      Still to confirm: 465, 587, 993, 995, 4190. Outbound 25 is **not needed**: RFC-wise, a smarthost relay carries our sending, and Scaleway Transactional Email is being set up for exactly that. Do not spend a support ticket on outbound 25.
+      Opened by the operator on 2026-11-01 (4190 is not offered by the provider — ManageSieve, not needed; leave it).
+      **Do not read a timeout from the agent host as "blocked".** Checked 2026-11-01 on both address families:
+      465/587/993/995 all time out while 80/443 answer in ~2 ms, and the same probe reaches the OLD box on those
+      ports instantly. But the new box has no mail app yet (the wizard is unsubmitted), so nothing is listening,
+      and Cloudron's own firewall drops rather than refuses by default — a permitted-but-empty port and a blocked
+      port are indistinguishable from outside. The 2026-10-30 IPv6 observation is the better evidence: those ports
+      were REFUSED there, which means the packet arrived, i.e. permitted. Verify for real once the mail app exists. Outbound 25 is **not needed**: RFC-wise, a smarthost relay carries our sending, and Scaleway Transactional Email is being set up for exactly that. Do not spend a support ticket on outbound 25.
       (Previous note, kept for the date: "Ports still to open on the new box (checked 2026-10-30): 25, 465, 587, 993, 995, 4190.")
 
       **Provider tier — confirmed 2026-11-01: Infomaniak VPS Cloud** (not Lite; the two differ
@@ -206,7 +212,7 @@ Status as of 2026-10-30:
       whole; the master password is what makes the restored contents readable. Note the shape of this:
       `vault.inference.coop` runs `com.github.bitwardenrs` — **Vaultwarden**, the open-source Bitwarden
       server — so official Bitwarden clients already work against it. There is nothing to sync.
-- [ ] **S3 `secretAccessKey`** — **confirm it is in the KeePass vault.** This is the one credential
+- [x] **S3 `secretAccessKey`** — **confirmed 2026-11-01: held externally by the operator along with the rest of the Infomaniak backup keys.** (A restore is unreadable without it, which is why it was flagged.) This is the one credential
       absent from the co-op's own off-box JSON (that carries `accessKeyId` only), and a restore begins
       by pointing the new Cloudron at the backup target — so it must be typeable before the window.
 - [ ] **Vault export** (optional insurance) — the contents already ride in the Cloudron backup, so this
@@ -307,7 +313,7 @@ by pre-cutover DNS plus port 25 — the point is that no *unexplained* failure a
   permanent data loss if they do not. Confirm against Cloudron's docs or the
   dashboard's backup contents before the freeze. This is now the most consequential
   open question in this runbook.
-- Whether the Vault export (§3 blocker) has actually been done.
+- ~~Whether the Vault export (§3 blocker) has actually been done.~~ **Closed 2026-11-01:** the operator confirms access to all relevant passwords outside the server. The full Vault export remains optional — the vault's own database is inside the Cloudron backup, so a restore returns it.
 - The Cloudron host's OS version, disk and RAM (not visible over the API).
 - Whether any provider API key is bound to our current IP.
 - Whether the subscription permits a server move.