backup: include gitea in PD postgres dumps

docs/operations/PD_BACKUP_DEPLOYMENT.md

@@ -35,7 +35,7 @@ PD_DATABASES_ROOT=/mnt/docker-ssd/docker/databases
 PD_TANK_DOCKER_ROOT=/mnt/tank/docker
 PD_DB_DUMP_ROOT=/mnt/tank/docker/backups/db-dumps
 POSTGRES_CONTAINER=shared-postgres
-POSTGRES_DB_LIST="n8n paperless"
+POSTGRES_DB_LIST="gitea n8n paperless"
 BACKUP_SSH_KEY=/home/truenas_admin/.ssh/serenity_backup_ed25519
 DOCKER_BIN=/usr/bin/docker
 SUDO_BIN=/usr/bin/sudo
@@ -54,7 +54,7 @@ mkdir -p /mnt/tank/docker/backups/db-dumps
 
 Confirm:
 
-- fresh `*.sql.gz` files appear in `/mnt/tank/docker/backups/db-dumps`
+- fresh `gitea_*.sql.gz`, `n8n_*.sql.gz`, and `paperless_*.sql.gz` files appear in `/mnt/tank/docker/backups/db-dumps`
 - appdata/database/tank-docker content lands under the chosen Serenity backup root
 - no sudo prompt appeared during `docker exec`
 
@@ -98,6 +98,8 @@ What it proves:
 - expected files still exist inside the restored sample
 - the latest run state can be exported to Prometheus via node-exporter's textfile collector
 
+Current expectation: `POSTGRES_DB_LIST` includes `gitea` so the backup set contains a logical dump for the Gitea database in addition to the raw synced Postgres data directory.
+
 ## Important limitations
 
 - Do **not** use `systemctl restart docker` on PD.
@@ -105,3 +107,4 @@ What it proves:
 - `rsync --delete` is intentional; use a dedicated destination root, not a shared miscellaneous folder.
 - This scaffolding does not yet back up `.env` files here because those are already handled by the separate encrypted/private-repo process.
 - If you insist on a non-root cron user on PD, you will need passwordless Docker access (`sudo -n /usr/bin/docker ...`) and write access to the chosen dump directory.
+- For Gitea, do not treat the live-synced Postgres datadir as the main restore proof; keep and verify the `gitea` logical dump as part of the normal restore-verification cycle.