CI gate: assert schema/schema.sql matches migrations (catch declarative-snapshot drift)

[tlongwell-block]

Problem

schema/schema.sql (the hand-maintained declarative snapshot that CI applies via pgschema apply in scripts/start-relay-for-tests.sh:93) can silently drift from migrations/0001_initial_schema.sql. There is no CI gate asserting the two produce identical schemas.

This bit the multi-tenant relay rewrite (#1321): the MT migration added community_id to ~22 tables (118 community_id refs in the migration), but the snapshot carried only 2. CI applied the stale snapshot, so e2e brought up a channels table with no community_id column and PRIMARY KEY (id) — diverging from what the migration and the relay code require (community_id NOT NULL, PRIMARY KEY (community_id, id)). The failure surfaced opaquely as downstream e2e 404s / insert failures rather than a clear "schema is out of date" signal.

Proposed gate

A CI check that:

1. Applies migrations/* to a fresh ephemeral Postgres.
2. Applies schema/schema.sql to a second fresh DB (or pgschema diff between the migration-built DB and the snapshot).
3. Fails red if the resulting schemas differ.

This makes snapshot drift impossible to merge: any migration that isn't reflected in the declarative snapshot (or vice versa) is caught at PR time with a clear diff, instead of surfacing as a confusing e2e failure later.

Notes

• pgschema diff is the natural primitive (already vendored at ./bin/pgschema, v1.7.4).
• Stylistic point: pgschema dump output does not byte-match the hand-maintained file format, so the check should compare normalized/semantic schema, not raw text — otherwise it'll be noisy on formatting alone.
• Not a blocker for Multi-tenant Buzz relay: community_id as a server-resolved key (comprehensive rewrite) #1321 (that PR fixes the specific drift directly); this is the class-killer so it doesn't recur.