Schema drift between production databases; migrator has no integrity check

[emooreatx]

Host inventory 2026-09-24 (information_schema.columns diff, US vs EU cirisnode, same image 5a617c4):

• evaluations — EU-only columns: batch_config jsonb, checkpoint_at timestamptz, completed_scenario_count integer NOT NULL, model_version varchar, trace_binding jsonb.
• frontier_models — EU-only: active bool NOT NULL, added_at, eval_config jsonb, id uuid NOT NULL, provider_label, proxy_route; created_at nullable on EU, NOT NULL on US.
• agent_events, audit_logs, jobs, wbd_tasks, agent_tokens, config — EU has archived integer (US boolean), timestamp (US timestamptz), text where US has jsonb (event_json, results_json, config_json). audit_logs.actor nullable varchar on EU vs NOT NULL text on US.
• schema_migrations: EU has an extra bare 006 row (applied 2026-02-09 23:57) alongside 006_add_evaluations. EU's migrations were applied by hand over 02-08..02-14; US in one pass on 02-15.

The app tolerates both shapes today (none of the EU-only columns are read in 5a617c4), so nothing is broken yet — but pg_dump-based data movement between them fails, and the next migration that assumes the US shape will behave differently per region.

Asks

1. cirisnode/db/migrator.py should verify schema shape, not just schema_migrations rows: after applying, compare information_schema.columns for the known tables against an expected manifest (or a checksum committed with each migration) and log/alert on drift. A bare 006 row should be rejected as an unknown version.
2. Make 001_ensure_core_tables.sql reconcile legacy types (archived integer → boolean, timestamp → timestamptz, text → jsonb with USING ::jsonb) so a hand-initialised DB converges instead of diverging forever.
3. Consider dropping the EU-only columns explicitly in a migration so the two shapes are identical, or adopt them in code if they were meant to land (checkpoint_at/completed_scenario_count look like CIRISBench's 002_add_checkpoint_columns alembic migration — the two apps migrate the same tables with two migration systems).

Context: CIRISAI/CIRISCore#2 consolidates onto the US database, which retires the EU shape; this issue is about not producing a new divergence.

[emooreatx]

Update 2026-09-25, after consolidating onto the US database (CIRISAI/CIRISCore#2): the EU-only evaluations / frontier_models columns are not dead weight — CIRISBench reads them. engine/db/models.py at 44198dd selects model_version, batch_config, completed_scenario_count, checkpoint_at, trace_binding and declares frontier_models.id/provider_label/active/proxy_route/eval_config/added_at. EU got them from bench's own Alembic chain (002_add_checkpoint_columns) run by hand in Feb; US never did. EU bench now logs Crash recovery check failed (non-fatal): UndefinedColumnError: column evaluations.model_version does not exist against US — and US bench has logged the same since February.

So the "schema drift" here is really two migration owners for one set of tables (CIRISNode's migrator.py 001–021 vs CIRISBench Alembic 001–004). Filed the ownership question as a CIRISBench issue; an additive CIRISNode migration adding the bench columns (ADD COLUMN IF NOT EXISTS, EU's defaults) is coming as a PR so the production schema matches what both apps expect. My earlier "nothing in 5a617c4 reads these" was correct for CIRISNode only.