fix(db): repair historical invitation revocation

TESTING.md

@@ -222,6 +222,38 @@ invitation admission paused, using the same traffic/writer controls if needed.
 It also requires `BUZZ_AUTO_MIGRATE` off: with auto-migration on (the Helm
 default), the old binary fails at startup with SQLx `VersionMissing(75)`. See
 [docs/database.md](docs/database.md) Rule 5.
+The separately approved companion provides the operator command:
+
+```bash
+psql -X -v ON_ERROR_STOP=1 -f scripts/maintenance/backfill_invite_revocations.sql
+```
+
+Run it as a top-level script, outside any caller transaction. The final query
+must report `0` unrepaired invites in active communities. Run it twice; the
+second run must keep zero and leave revocation timestamps and markers unchanged.
+Review fenced communities separately and keep their admission closed until they
+can be repaired under the same controls.
+
+Use a **fresh disposable database through migration 0074**, the complete
+pre-change schema including channel join roles, for upgrade testing. Do not reuse
+an older database that applied an invitation migration under an earlier number
+or a different 0075 checksum; reconcile it separately without resetting a user's
+database. Seed legacy links for a restricted issuer and an unrelated issuer;
+lift the first restriction before
+upgrade. Apply schema-only 0075 and confirm it rewrites no invite rows. Before
+repair, signed claims reject historical legacy candidates lazily. Run the actual
+repair script twice, checking selective revocation, cleared markers, zero
+remaining active-community legacy rows and idempotence. The populated automated
+fixtures also exercise real `bin/pgschema apply --file schema/schema.sql`, then
+`scripts/reconcile-schema-after-pgschema.sql` twice, for outcome parity.
+
+After repair, a newly applied timeout/mute must temporarily block claims without
+durable revocation; after expiry the same link works. Ban via the authorized
+owner path and verify permanent rejection, even after unban and relay restart.
+A fresh replacement minted by an unrestricted issuer must work. Include current
+owner restrictions, noncanonical issuers, community/deletion fences, and the
+marker-clearing lock-serialization tests in the full PostgreSQL lane.
+
 Legacy owner attribution uses the agent's currently recorded
 `agent_owner_pubkey`; deleting an owner user row out of band clears that link
 through its foreign key, so a later repair cannot recover the former

crates/buzz-db/TESTING.md

@@ -68,5 +68,6 @@ Invite upgrade tests start from the complete schema through migration 0074,
 including channel join roles, entity deletion approval, the unlisted channel setting and the user deletion target and fences. They exercise the
 invitation schema expansion (migration 0075) through both migration and
 desired-state paths against populated
-data, retaining a non-default channel join role. Historical repair is validated
-separately from the application/schema change.
+data, retaining a non-default channel join role. They also execute the operator
+repair script with `psql`; make sure the PostgreSQL client is installed and
+resolves on `PATH`.

crates/buzz-db/src/store/relay_invite/revocation_postgres_tests.rs

@@ -317,6 +317,7 @@ async fn stalled_production_mint_ignores_lifted_history_and_later_audit_touches(
         .unwrap();
     }
 
+    super::upgrade_postgres_tests::run_invite_repair_script(&pool).await;
     let revoked: Option<chrono::DateTime<chrono::Utc>> =
         sqlx::query_scalar("SELECT revoked_at FROM relay_invites WHERE community_id=$1 AND id=$2")
             .bind(community.as_uuid())