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>

tests/mattermost-lts/PARITY.md

@@ -11,17 +11,24 @@ mattermost-lts ships no `test_<op>.py` overlays, so the **generic** install/upgr
 tiers run by default (the Phase-1e invariant: no overlay ⇒ generic runs). The stack bundles its own
 postgres in-compose (no external dep), so no dependency resolution is needed.
 
-## P3 — Recipe-specific functional tests
-- `functional/test_health_check.py`
-  - `test_root_serves` — web app served at `/` (200/302).
-  - `test_system_ping_ok` — GET `/api/v4/system/ping` → `{"status":"OK"}` (proves the mattermost
-    server + API router are live, not a Traefik fallback).
-- `functional/test_create_message.py` — **§4.3 prescribed create-an-object + read-it-back** (planned,
-  authored against the live instance): create the first user (system admin) → login → create team →
-  create channel → POST a message → GET it back → assert the message text round-trips. *(In progress —
-  requires response-header access for the mattermost login `Token`; harness.http extension pending.)*
+## P3 — Recipe-specific functional tests (≥2 separate characteristic tests)
+1. `functional/test_create_message.py::test_create_message_roundtrip` — **§4.3 create-an-object +
+   read-it-back**: first user (system admin) → login → create team → create channel → POST a unique
+   marker message → GET it back by id → assert the text round-trips.
+2. `functional/test_multiuser_message.py::test_second_user_reads_first_users_message` — the defining
+   **team-chat** behaviour (distinct code path: membership + ACL + cross-user delivery): user_a posts a
+   unique marker; a SECOND user (created via admin API, added to team+channel) logs in with its own
+   session and GETs the channel posts → asserts it sees user_a's message. Not a self read-back.
+- `functional/test_health_check.py` — `test_root_serves` (`/` 200/302) + `test_system_ping_ok`
+  (`/api/v4/system/ping` → `{"status":"OK"}`, API liveness). Supporting health/liveness, not counted
+  toward the P3 ≥2 floor.
 
-## P4 — Backup data-integrity
-Planned `ops.py`: pre_backup seeds an identifiable message via the API; pre_restore mutates/wipes;
-the restore assertion re-reads the message and asserts it survived (recipe-aware, not health-only).
-*(Follows once the create-message API flow is proven green.)*
+## P4 — Backup data-integrity (real)
+`ops.py` seeds a postgres `ci_marker` row (psql in the `postgres` service); `test_backup.py` asserts
+it at backup time, `test_restore.py` asserts it survives restore, `test_upgrade.py` asserts it survives
+the upgrade. **Requires recipe-PR `recipe-maintainers/mattermost-lts#1`**: the published recipe dumped
+the DB on backup but shipped NO `backupbot.restore.post-hook` and archived the whole live PGDATA dir,
+so a restore extracted files under the running postgres without reloading them → the DB silently kept
+the un-restored state (`test_restore_returns_state` RED). The PR switches to the coop-cloud
+`/pg_backup.sh` convention (dump-only backup + terminate/FORCE-drop/recreate/reimport restore); with it
+the ci_marker survives backup→restore. See DECISIONS.md "mattermost-lts postgres restore recipe-PR".