Stele's migration chain and loomworks-engine's migration chain both use the default alembic_version table name, with neither configuring a distinct one. When both are run against a shared database, they collide — Stele's own alembic upgrade head fails outright ("Can't locate revision identified by '0097'") because it finds the engine's stamp and doesn't recognize it. There is no simple missing command to run; the two chains genuinely cannot be synced with standard tooling today. Confirmed as the root cause of a test-database schema drift (a Stele column, principals.totp_last_step, never applied to the engine's test DB) that caused 864 test failures, worked around with a one-off manual fix — this CR is the permanent structural correction.
In stele/src/stele/migrations/env.py, add version_table="stele_alembic_version" to context.configure(...), both the online and offline call sites. This gives Stele's migration chain its own tracking table, distinct from the engine's default alembic_version, so both chains can be run independently — including a plain alembic upgrade head from Stele's own directory — against a shared database without collision. No change needed on the engine side; its migrations keep using the default table name untouched.
No conflict. Infrastructure correctness fix, no user-facing or Operator-facing change.
The one-off manual column fix already applied to unblock today's testing (this CR is the permanent replacement for that workaround, not an addition to it). CR-2026-149 (unrelated production bug, same investigation surfaced both).