Migrations are never exercised by CI, and autogenerate cannot see type/default drift

[raullopez-sandbox]

The gap

Two independent holes that compound into one: a wrong migration ships green.

1. core/tests/conftest.py builds the test schema with Base.metadata.create_all(). The alembic chain is never applied, so no test asserts that the migrations actually produce the schema the models describe. A migration can be wrong — or missing entirely — and the whole suite passes.

2. core/switch_core/migrations/env.py sets neither compare_type nor compare_server_default on the alembic context. Without them, alembic revision --autogenerate cannot see a column whose type or server default diverges from the model. It reports an empty diff and looks like confirmation.

alembic heads does not close this — it reads the revision graph, not the database.

Why it matters

The failure mode is the bad one: it looks fine. Green suite, empty autogenerate diff, wrong column in production. Nothing in the current setup can distinguish "the migrations are correct" from "the migrations are never run."

Suggested fix

• Turn on compare_type=True and compare_server_default=True in env.py so autogenerate can actually detect drift. Expect this to surface pre-existing diffs on the first run — those need triaging before the flag is useful as a gate.
• Add a CI job that applies the full chain (alembic upgrade head) against a throwaway Postgres from empty, then asserts the resulting schema matches Base.metadata. Round-tripping downgrade -1 / upgrade head catches non-reversible revisions at the same time.
• Optionally, a test that fails when the models have changed without a corresponding revision — autogenerate against head must produce an empty diff.

Not urgent, but load-bearing

Filed rather than fixed inline because it is orthogonal to any feature branch and deserves its own review. Noticed while hand-verifying a migration.