dns: add the migration change sheet; correct AAAA scope, close the mount unknown

Live zone inventory: 19 A + 18 AAAA records, all TTL 3600 (the lower values
seen on some answers are cache countdowns). The AAAA scope was understated
in the runbook - it is 18 hostnames, not 3. No CAA records, so no CA
restriction to update. The /var/lib/nextcloud host mount resolves to 3 MB of
regenerable thumbnails, so it is no longer an open unknown.

cloudron-server-migration.md

@@ -42,6 +42,8 @@ and the agent's own state (different machine).
 
 ## 3. Pre-flight
 
+Companion sheet: `dns-change-sheet.md` (every record, current value, target value).
+
 **Blocker — do this first.** The Vault app (`vault.inference.coop`) runs *on the server
 being migrated*, and the backup passphrase is believed to live there. The credentials
 needed to restore are inside the thing being restored.
@@ -57,8 +59,9 @@ needed to restore are inside the thing being restored.
       old box's (9.0.4).
 - [ ] Confirm the Cloudron subscription can be moved to a new server.
 - [ ] **Decide the IPv6 question before anything else DNS-related.** The zone carries
-      **AAAA records**: `inference.coop`, `my`, `matrix` all point to
-      `2a02:4780:6e:83fd::1` (Hostinger's range). If the new box has IPv6, repoint them;
+      **AAAA records on 18 hostnames** — everything that has an A record — all pointing to
+      `2a02:4780:6e:83fd::1` (Hostinger's range). Counted 2026-10-30; the full list is in
+      `dns-change-sheet.md`. This is 18 deletions or repoints, not a footnote. If the new box has IPv6, repoint them;
       if it does not, **delete the AAAA records** as part of the switch. Changing only
       the A records leaves every IPv6-capable client — including other Matrix
       homeservers and mail senders — still reaching the old box.
@@ -82,8 +85,9 @@ needed to restore are inside the thing being restored.
         --format '{{.Name}} {{range .Mounts}}{{.Source}}=>{{.Destination}} {{end}}' \
         | tr ' ' '\n' | grep -v /app/data
 
-      A container showed `/var/lib/nextcloud` mounted from the host. Identify its owner and
-      size; if it holds real data, copy it separately.
+      **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.
 - [ ] 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
@@ -161,7 +165,6 @@ needed to restore are inside the thing being restored.
 ## 7. Open unknowns — resolve before cutover
 
 - Whether the Vault export (§3 blocker) has actually been done.
-- Which app owns the `/var/lib/nextcloud` host mount, and how much data is in it.
 - 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.