fix(api): widen alembic_version.version_num in migration 001 (CAR-1302)

Alembic hardcodes alembic_version.version_num to VARCHAR(32) in
DefaultImpl.version_table_impl, and version_table_column_width is NOT a
real kwarg that context.configure() honors — it's silently ignored, so
the env.py change alone was never going to take effect on a fresh DB.

Our descriptive revision ids exceed 32 chars (e.g. 003_make_users_hashed_
password_nullable = 39, common 002_add_normalized_products_upc_variants_
index = 46), so the 003 / common 002 stamp fails with StringDataRight-
Truncation, the whole chain rolls back, and the column is recreated at
VARCHAR(32) on the next attempt.

Fix:
- api/alembic/versions/001_encrypt_session_data.py: insert ALTER TABLE
  alembic_version ALTER COLUMN version_num TYPE VARCHAR(128) as the very
  first statement of upgrade(), before any early-return path. Idempotent
  when the column is already wider (e.g. the CAR-1298 one-shot Job).
- common/alembic/versions/001_add_email_inbound_token.py: same defensive
  ALTER as the first statement of upgrade() (common is a library, not
  deployed, but the 46-char 002 id would have hit the same trap).
- api/alembic/env.py: remove the phantom version_table_column_width=128
  kwarg from both context.configure() call sites — it was a no-op and
  misled the original investigation.

No downgrade() changes: a matching narrowing could truncate.

Refs CAR-1302 (durable root fix), CAR-1298 (prod workaround this
replaces). Verified against a fresh PostgreSQL — all 9 api migrations
upgrade head with no StringDataRightTruncation, and common 001/002 stamp
the 46-char id cleanly. Cluster has pgcrypto enabled by the operator.

Co-Authored-By: Paperclip <noreply@paperclip.ing>

api/alembic/env.py

@@ -31,7 +31,6 @@ def run_migrations_offline() -> None:
         target_metadata=target_metadata,
         literal_binds=True,
         dialect_opts={"paramstyle": "named"},
-        version_table_column_width=128,
     )
     with context.begin_transaction():
         context.run_migrations()
@@ -45,7 +44,7 @@ def run_migrations_online() -> None:
         poolclass=pool.NullPool,
     )
     with connectable.connect() as connection:
-        context.configure(connection=connection, target_metadata=target_metadata, version_table_column_width=128)
+        context.configure(connection=connection, target_metadata=target_metadata)
         with context.begin_transaction():
             context.run_migrations()
         # Create any tables defined in models but not yet created by migrations.

api/alembic/versions/001_encrypt_session_data.py

@@ -33,6 +33,15 @@ def _is_fernet_token(value: str) -> bool:
 
 
 def upgrade() -> None:
+    # Alembic hardcodes alembic_version.version_num to VARCHAR(32)
+    # (DefaultImpl.version_table_impl) and exposes no option to widen it
+    # (version_table_column_width is NOT a real kwarg — it is silently ignored).
+    # Our descriptive revision ids exceed 32 chars (e.g.
+    # 003_make_users_hashed_password_nullable = 39), so widen the column as the
+    # very first migration statement, before any early-return path below.
+    # Idempotent: a no-op when already wider (e.g. pre-created by the CAR-1298 Job).
+    op.execute("ALTER TABLE alembic_version ALTER COLUMN version_num TYPE VARCHAR(128)")
+
     conn = op.get_bind()
     inspector = sa.inspect(conn)
 

common/alembic/versions/001_add_email_inbound_token.py

@@ -18,6 +18,11 @@ depends_on: str | Sequence[str] | None = None
 
 
 def upgrade() -> None:
+    # Same VARCHAR(32) alembic_version limitation as the api migrations; the
+    # common 002 revision id is 46 chars. Widen first so a fresh-DB upgrade can
+    # stamp it. Idempotent.
+    op.execute("ALTER TABLE alembic_version ALTER COLUMN version_num TYPE VARCHAR(128)")
+
     op.add_column("users", sa.Column("email_inbound_token", sa.String(22), nullable=True))
     op.create_unique_constraint("uq_users_email_inbound_token", "users", ["email_inbound_token"])