migration: add the before-state snapshot; S3 secret is NOT off-box

Snapshot records apps/images/env-names/backup config and data fingerprints for a
post-restore diff. Also resolves an open unknown: the off-box JSON carries only
accessKeyId, so the S3 secretAccessKey must be retrieved before the window. The
restic passphrase is fine - it is on the agent host, which is not migrating.

cloudron-server-migration.md

@@ -50,9 +50,16 @@ needed to restore are inside the thing being restored.
 
 - [ ] Export the Vault contents and store them off-server (personal password manager or
       offline media). Confirm the **Cloudron backup passphrase** is in your own hands.
-- [ ] Confirm the backup target's S3 access key is available off-box. The agent host has
-      `~/.hermes/security/backup_sites_backup.json` (0600) — check whether it carries the
-      key; if not, retrieve it from the Infomaniak console.
+- [ ] **Retrieve the S3 secretAccessKey — the off-box copy does NOT have it.** Checked
+      2026-10-30: `~/.hermes/security/backup_sites_backup.json` carries `accessKeyId` and
+      nothing else. A restore begins by pointing the new Cloudron at the backup target, so
+      the *secret* must be in hand before the window — get it from the Infomaniak console
+      and store it with the passphrase, off-box.
+- [x] The **restic** passphrase is safe: `~/.hermes/scripts/backup.sh` documents that
+      `RESTIC_PASSWORD` lives in the agent host's `.env` **and** the co-op Vault. The agent
+      host is not being migrated, so the agent-side backup stays recoverable. (The Vault,
+      however, is an app on the box being migrated — so the Vault copy alone is not
+      off-box until it is exported.)
 - [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.
 - [x] OS: **Ubuntu 26.04 LTS is supported** — Cloudron's install docs specify a fresh
@@ -151,6 +158,16 @@ needed to restore are inside the thing being restored.
       advance, so a strict-host-key refusal doesn't stop you mid-migration.
 - [ ] Announce the window in `#updates`.
 
+## 3a. The "before" snapshot
+
+`migration-before-state.json` in this repo is a machine-diffable record of the current
+server: 16 apps with their manifest ids, image tags, state, health and **env var names**
+(never values); the backup sites, schedule and retention; the newest run's id, state,
+integrity signature and size; Cloudron's version; and data fingerprints (member count,
+API-key count, ledger rows, `metrics_daily` rows, Gitea repo count). Capture nothing
+further; after the restore, diff it. A silently-empty app is exactly what a diff catches
+and a spot-check misses.
+
 ## 4. Cutover, in order
 
 1. **Freeze writes.** Pause the portal's `membership_sweep` and `rag_refresh`, hold
@@ -222,7 +239,6 @@ needed to restore are inside the thing being restored.
   open question in this runbook.
 - Whether the Vault export (§3 blocker) has actually been done.
 - The Cloudron host's OS version, disk and RAM (not visible over the API).
-- Whether the S3 access key is in the off-box JSON or only inside Cloudron.
 - Whether any provider API key is bound to our current IP.
 - Whether the subscription permits a server move.