migration: point §5 at verify-restore.py, the executable post-restore check

Diffs the restored server against migration-before-state.json: app inventory, env var names, image tags, backup target, portal row counts, DNS, federation, mail ports, site responses. Dry run 2026-10-30: 50 pass / 1 warn / 13 fail, every failure explained by pre-cutover DNS or port 25.

cloudron-server-migration.md

@@ -196,6 +196,17 @@ and a spot-check misses.
 
 ## 5. Post-restore verification
 
+Run `python3 ~/.hermes/scripts/verify-restore.py` from the **agent** host — it stays up through the
+migration, so it is the one machine that can judge the new box. It diffs the restored server against
+`migration-before-state.json`: app inventory, **env var NAMES** (a lost var comes back as an app that
+will not start), image tags, backup target and schedule, portal data fingerprints (row counts must
+never drop), DNS, federation, mail ports, and whether each site answers. Exit 1 = at least one
+regression. `--quiet` prints failures and warnings only; `--only <group>` runs one group.
+
+Run it **before** cutover too: DNS and port-25 failures are expected then, and they are exactly what
+cutover is meant to clear. The 2026-10-30 dry run gave 50 pass / 1 warn / 13 fail, all 13 explained
+by pre-cutover DNS plus port 25 — the point is that no *unexplained* failure appears.
+
 - [ ] Dashboard loads with a valid certificate; all 16 apps `running`.
 - [ ] **One custom app loads** — e.g. `panel.inference.coop`. This is the proof the
       registry restored; without it nothing custom starts.