feat(2): mattermost-lts P3 2nd characteristic test (multi-user message visibility) + PARITY/DECISIONS for the postgres-restore recipe-PR

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

machine-docs/DECISIONS.md

@@ -919,3 +919,16 @@ connections + `DROP DATABASE … WITH (FORCE)` + `createdb` + reimport (the matr
 trick does NOT cover immich-server's *networked* connections, so FORCE-drop is required). The
 VectorChord/pgvecto.rs extensions (vchord, vector) + all tables round-trip cleanly — validated live,
 then proven green end-to-end via `RECIPE=immich PR=1` (restore tier `test_restore_returns_state` PASS).
+
+## mattermost-lts postgres restore recipe-PR (Phase 2 Q4.5 P4) — 2026-05-30
+**Decision:** fix mattermost-lts's broken DB restore with a recipe-PR (`recipe-maintainers/mattermost-lts#1`),
+mirroring the immich precedent. The published recipe's `postgres` service dumps the DB on backup
+(pg_dump pre-hook) but ships NO `backupbot.restore.post-hook`, and archived the whole live PGDATA dir
+(`backup.path=/var/lib/postgresql/data/`). backupbot's restore extracts the files under the running
+postgres, which does NOT reload PGDATA without a restart → the live DB keeps the un-restored state.
+Proven by the P4 overlay: `test_restore_returns_state` RED (`relation "ci_marker" does not exist`).
+**Fix:** switch to the coop-cloud `/pg_backup.sh` convention (as matrix-synapse): config-mounted
+script, `backup` = pg_dump|gzip → backup.sql, `backupbot.backup.volumes.postgres_data.path=backup.sql`
+(archive only the dump), `restore` post-hook = terminate connections + DROP DATABASE FORCE + createdb
++ reimport. postgres:15 plain dump → no special handling (mechanism already proven generic on immich).
+Validated: `RECIPE=mattermost-lts PR=1` full lifecycle GREEN, restore tier PASSES (ci_marker survives).