[argiad]

Fixes five self-host installer gaps that an independent review of the install guides (#155) turned up. Each one was documented in the guides as a workaround; this PR fixes them and drops those workarounds from the docs.

Builds on #155 (merged): the doc edits are on top of its guides.

The five gaps

1. Moving to a new release (owner's call: mmctl upgrade --to <tag>). Plain mmctl upgrade only re-pulled the pins already installed. --to first downloads the tag, so a wrong tag changes nothing. It refuses a release older than the installed one, because the database migrates forward only. Then it takes and verifies a backup, swaps /opt/mm/src, and runs that release's installer with the install's own domain, email and mode. --to main moves to the newest release. Separately, install.sh now backs up a completed install before re-running over it (the one-liner fetches main, which migrated the DB with no backup). A failed backup stops it; MM_SKIP_BACKUP=1 overrides.
2. A re-run failed after the owner changed the generated password. Fixing this turned up a bigger bug (below), and the fix is a dedicated admin account for mm-core.
3. The preflight AAAA check never ran: install.sh set MM_DOMAIN after preflight. The domain is now passed in. The check now also ignores the IPv4-mapped ::ffff: answers glibc returns for A-only names; without that it would have warned on every IPv4-only domain.
4. No CPU architecture check. On ARM, preflight now stops before installing anything and names the architecture it found.
5. Backups. Files are written 0600 in a 0700 dir, and older 0644 backups are tightened. Sets older than MM_BACKUP_KEEP_DAYS (default 14, 0 keeps all) are pruned, only after a fully successful backup. The config tarball now carries Synapse's signing key and versions.env + docker-compose.yml, so mmctl restore after a release upgrade brings back the old image pins. mmctl restore also puts the key back. mmctl backup --media (opt-in, owner's call) archives the synapse-data and recordings-data volumes.

The bigger bug behind gap 2: mm-core's admin token was the owner's session

MM_SYNAPSE_ADMIN_TOKEN was a session of the owner's account. A Matrix password change logs out the user's other devices by default (logout_devices defaults to true), so an owner who changed the generated password, as the guides told them to, revoked mm-core's token. After that:

• the Operator Console signed them in as demo (check_synapse_admin(...).unwrap_or(false));
• membership gates and moderation failed closed;
• every re-run died with could not capture admin token.

Every use of the token is a Synapse admin API call, so with the owner's OK it now belongs to @mm-core:<domain>, an admin account with a generated password (MM_SYNAPSE_SERVICE_PASS) that no person signs in with.

• Re-runs keep a token that still works (whoami) or sign @mm-core in again. They never need the owner's password, and leave the owner account alone unless --admin-user/--admin-pass is passed.
• An existing install switches over on its next install.sh re-run. The old owner session is signed out only after mm-core is healthy on the new token.
• mmctl rotate MM_SYNAPSE_ADMIN_TOKEN signs @mm-core in again without a prompt. It signs the old token out after phase 3, so the phase-0 rollback still works.
• Passwords and tokens reach curl and register_new_matrix_user on stdin, never on a command line.

Live installs where the owner already changed the password are affected today. One re-run of the new installer fixes them.

Tests

• TDD throughout: each new test was watched failing first. The suite went from 274 to 347 bats tests, all green, and shellcheck is clean (macOS bash 3.2 / BSD tools locally; CI runs them on Ubuntu/GNU).
• An independent review pass found six issues, all fixed in the last commit: token retirement order, the password on argv, the AAAA false positive, the in-place key write, ordering in upgrade --to, and stale stage dirs.

Not verified on a real server. Creating the Hetzner test server was blocked in this session (auto-mode classifier), so @mm-core provisioning, --password-file /dev/stdin, the switch-over from an owner token, and upgrade --to against a live stack are covered by unit tests only. A fresh-server run is worth doing before the next release. The plan is in the session notes.

CI fix included (separate commit)

ci(test): give each cargo-test run its own database. The mm-runners jobs share one host Postgres, and every run reset the same mm_test. Overlapping runs broke each other in one of two ways: dropdb was refused (this PR, twice), or it dropped the database under live tests (development's push run after #155). Each run attempt now uses mm_test_<run_id>_<attempt> and drops it at the end. cargo-test is a required check, so this was blocking every PR.

Docs

• docs/install.md, docs/install-agent.md and deploy/README.md drop the workarounds: the manual backup plus pinned re-run, --admin-pass on re-runs, "write the new password down", the find -delete cron line, and the manual AAAA check. They now document upgrade --to, backup --media, retention, @mm-core, and new troubleshooting rows.
• deploy/docs/secrets-inventory.md and rotation-runbooks.md are updated for @mm-core. docs/upgrade-guide.md points single-server installs at upgrade --to. CHANGELOG has Unreleased entries.

🤖 Generated with Claude Code