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

## 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 #1321 (that PR fixes the specific drift directly); this is the class-killer so it doesn't recur.