Finish RPF-WP-0019 apps-pg controls and recovery

docs/evidence/RPF-WP-0019-isolation-2026-08-20.md

@@ -0,0 +1,65 @@
+# RPF-WP-0019 — apps-pg isolation evidence
+
+Date: 2026-08-20
+
+Live target: railiance01 / `databases/apps-pg`
+
+Harness: `make apps-pg-isolation-probe`
+
+The repeatable harness creates a labeled temporary namespace, projects the two
+existing consumer Secrets into isolated probe pods without printing their
+values, exercises the real consumer credentials over the service endpoint,
+and deletes the namespace on exit.
+
+## Finding before the passing run
+
+The first privilege preflight found that `apps_meta`, `vergabe_db`, and
+`coulomb_social_db` retained PostgreSQL's default `PUBLIC` `CONNECT` and
+`TEMPORARY` privileges. A database-per-consumer declaration was therefore not
+yet a database connection boundary. The controlled SQL now revokes both
+privileges from `PUBLIC` on all three databases and grants them only to each
+database's owner. The passing run occurred after that correction; the failed
+precondition is not counted as a pass.
+
+## Consumer boundary
+
+All eleven assertions passed:
+
+- each role connected to its own database through the live RW Service;
+- each role was denied connection to the peer database;
+- `coulomb_social` was denied connection to `apps_meta`;
+- a consumer could not alter the peer role;
+- an own-database table remained readable;
+- the real credential observed both 15-second timeouts and connection limit
+  20; and
+- a 20-second statement was terminated by `statement_timeout`.
+
+## Noisy-neighbour run
+
+The harness measured five sequential `vergabe` queries, filled every available
+`coulomb_social` role slot with client-side-idle sessions, verified 20 live
+connections, and attempted one more connection.
+
+| Observation | Result |
+| --- | --- |
+| `vergabe` baseline, five queries | 5,285 ms |
+| `coulomb_social` at ceiling | 20 connections |
+| excess `coulomb_social` connection | denied |
+| `vergabe` during saturation, five queries | 8,146 ms |
+| measured wall-time increase | 54.1% |
+| victim availability | 5/5 queries succeeded |
+
+The timings include five separate API/exec/process startups, so they are an
+operator-path comparison rather than an application latency benchmark. Both
+co-residents declare `interactive`, but neither declares a numeric database
+latency objective. The result therefore supports the P1 consumer-boundary and
+availability claim: one consumer exhausted its own allowance, the control
+bound, and the peer retained service. It does **not** establish a latency SLO,
+CPU fairness, memory fairness, tenant isolation within either consumer, HA, or
+P2 placement.
+
+## Result
+
+`14 passed, 0 failed`. Production `apps-pg` remained Ready with continuous
+archiving and the last backup healthy; `deployment/coulomb-social` remained
+1/1 Ready. The temporary probe namespace was deleted.