Closes #132. Neither stack had a backup of any kind, so losing the
server's disk lost the board and every account on the PDS — the
encryption at rest protects the rows from a reader, not from an absence.

The three questions the issue asked, answered:

*What a backup is.* One encrypted archive holding the pg_dump, the PDS's
SQLite databases, its blobstore, the Data Protection keys, and the
stack's env file. That last one is the decision worth arguing with: a
dump of this database is enc:v1: ciphertext and ENCRYPTION_KEY is not in
it, so a backup without the env file restores to nothing on the day the
machine holding it died. Carrying it is what makes a rebuild need
exactly two things — the archive and a passphrase kept off the server —
and it is why the whole archive is encrypted rather than merely
compressed.

The PDS half is not a tar. That PDS runs SQLite in WAL mode with almost
everything in the -wal, so a copy that raced it would restore a database
that opens cleanly and is empty: measured on 0.4.5027, a straight copy
of a live account.sqlite reports 0 objects in sqlite_master where
SQLite's own online backup of the same file reports 52. So every
*.sqlite goes through `sqlite3 .backup` and is integrity-checked, and
the databases are captured before the blobstore, because a blob is
uploaded before the record referencing it is written.

*Where it goes.* Outward, on the host's own timer beside
ponente-update@, for the same measured reason the updater polls rather
than being pushed to. BACKUP_REMOTE is an rclone destination and rclone
runs as a container, so the provider is a config file rather than a code
change. With no remote the backup still runs and stays on the host, and
every run says so on stderr.

*How a restore is proven.* Every run, before the archive counts: the
dump is restored into a scratch Postgres of the same image and queried,
every SQLite copy is integrity-checked, and the finished file is
decrypted back and compared by sha256. A run that cannot verify writes
no archive at all. restore.sh adds the drill (verify an archive,
changing nothing) and the disaster (--stack, which replaces the
database, the PDS volume and the keys), and deploy/backups.md carries
the bare-metal rebuild.

Production only; dev's board is throwaway by design and leaves it off.

Rehearsed end to end in CI against a stand-in stack — a live PDS
container, this repository's schema as applied by the app, and MinIO as
the remote: full run, damaged-stack restore, prune, fetch-back-and-
restore, and the failure paths (wrong passphrase, tampered archive,
missing passphrase, no remote). That rehearsal is also what found the
scratch-Postgres readiness race this waits on `select 1` for: the
official image accepts socket connections while it is still creating
POSTGRES_DB, so pg_isready says yes and the restore then dies on
`database "ponente" does not exist`.

@@ -0,0 +393,4 @@
+
+    # The config goes into a named volume rather than a bind mount: a rootless
+    # bind mount of a file in the podman user's home is the one part of this
+    # that behaves differently under SELinux, and there is no reason to find

@@ -0,0 +393,4 @@
+
+    # The config goes into a named volume rather than a bind mount: a rootless
+    # bind mount of a file in the podman user's home is the one part of this
+    # that behaves differently under SELinux, and there is no reason to find