Consolidate migrations 001–023 into one baseline schema

023_schema.sql is the whole database as the 23 migrations left it:
every table in its final shape (columns added by ALTER folded into
their CREATE), its indexes, the five views, the seed rows (event
scopes, the shipped front page) and the triggers, last. The reasoning
from the old files that still applies sits next to what it explains;
the rest is in git history.

A fresh database runs it and lands at v23; one already at v23 skips
it. migrate() now treats the first file as a baseline and refuses a
database between v1 and v22 with a message saying to upgrade it on
an older release first, rather than failing halfway on CREATE TABLE.
Production is at v19, so the previous commits on this branch
(020–023) have to be deployed before this one.

Checked by building a database from the old files and one from this
file and comparing them: strictness, columns, types, defaults,
nullability, keys, foreign keys and their actions, CHECK constraints,
index definitions, view and trigger SQL, and seed rows all match.

Comments that cited migration numbers now point at the schema, and
CLAUDE.md describes the baseline and where new migrations go.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

CLAUDE.md

@@ -69,9 +69,10 @@ Descriptor-driven: `server/admin-crud.js` and `admin-schema.js` (server) and `ad
 - `admin-cli.js` imports `ROLES` and `destroyAllSessionsFor` from `auth.js`. Keep it that way to prevent drift.
 
 ## Migrations
-- Sequential files: `001_`, `002_`, ...
-- The runner may drop statements after a `BEGIN...END` trigger body. Put each `CREATE VIEW` in its own migration file with no `BEGIN...END` block.
-- The runner turns foreign keys off around every migration (it can't be done inside the file's transaction) and runs `PRAGMA foreign_key_check` before committing, so a table rebuild needs no `PRAGMA foreign_keys` of its own. A rebuild whose table is named by views or triggers wraps the rename in `PRAGMA legacy_alter_table = ON ... OFF` (see 023).
+- `server/src/migrations/023_schema.sql` is the baseline: the whole schema, consolidated from the old 001–023. It only runs on an empty database; the runner refuses a database between v1 and v22. It's the place to read the schema, not to change it: a database that already exists never re-runs it.
+- Changes go in new sequential files after it: `024_`, `025_`, ...
+- The runner may drop statements after a `BEGIN...END` trigger body. Keep triggers last in a file, and put each `CREATE VIEW` before any trigger or in its own file.
+- The runner turns foreign keys off around every migration (it can't be done inside the file's transaction) and runs `PRAGMA foreign_key_check` before committing, so a table rebuild needs no `PRAGMA foreign_keys` of its own. When views or triggers name the table being rebuilt, wrap the drop-and-rename in `PRAGMA legacy_alter_table = ON` ... `OFF`, then recreate the rebuilt table's own indexes and triggers.
 
 ## Integrations
 - Church Center (ngu.churchcenteronline.com): Planning Center embeds for giving and the calendar.