alembic: make migration chain SQLite-compatible (fresh upgrade)

Five existing migrations used op.alter_column / op.create_unique_constraint /
op.drop_constraint / op.create_foreign_key directly on the users + quotes +
quotes_daily tables. SQLite has no native support for those operations and
requires Alembic's batch_alter_table copy-and-rename workaround.

This wasn't noticed until now because the test suite uses
Base.metadata.create_all to materialise schema, not the migration chain
itself; and prod is MariaDB. But running `alembic upgrade head` against
a fresh SQLite database (developer onboarding, CI smoke tests, the
test container's own bootstrap) would fail at 0005.

Fixes:
- alembic/env.py: set render_as_batch=True when the dialect is SQLite.
  This auto-wraps any future autogenerated migration but doesn't
  retroactively rewrite existing op.* calls.
- 0005 (widen quotes.symbol), 0013 (referrals), 0018 (polar webhook),
  0019 (stripe), 0023 (users.lang index + qd_symbol widen) explicitly
  wrap their problematic ops in `with op.batch_alter_table(...) as bop`.

Now `alembic upgrade head` + `alembic downgrade base` round-trip cleanly
on a fresh SQLite database. MariaDB prod behaviour unchanged.

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

alembic/versions/0013_referrals.py

@@ -30,23 +30,21 @@ depends_on: Union[str, Sequence[str], None] = None
 
 
 def upgrade() -> None:
-    op.add_column(
-        "users",
-        sa.Column("referral_code", sa.String(16), nullable=True),
-    )
-    op.create_unique_constraint(
-        "uq_users_referral_code", "users", ["referral_code"],
-    )
-    op.add_column(
-        "users",
-        sa.Column("referred_by_user_id", sa.Integer, nullable=True),
-    )
-    op.create_foreign_key(
-        "fk_users_referred_by",
-        "users", "users",
-        ["referred_by_user_id"], ["id"],
-        ondelete="SET NULL",
-    )
+    # batch_alter_table wraps ADD CONSTRAINT in a copy-and-rename for
+    # SQLite (no native ALTER constraints support); on MariaDB/Postgres
+    # it falls through to plain ALTER statements.
+    with op.batch_alter_table("users") as bop:
+        bop.add_column(sa.Column("referral_code", sa.String(16), nullable=True))
+        bop.create_unique_constraint(
+            "uq_users_referral_code", ["referral_code"],
+        )
+        bop.add_column(sa.Column("referred_by_user_id", sa.Integer, nullable=True))
+        bop.create_foreign_key(
+            "fk_users_referred_by",
+            "users",
+            ["referred_by_user_id"], ["id"],
+            ondelete="SET NULL",
+        )
 
     op.create_table(
         "referrals",
@@ -71,7 +69,8 @@ def upgrade() -> None:
 def downgrade() -> None:
     op.drop_index("ix_referrals_referrer", table_name="referrals")
     op.drop_table("referrals")
-    op.drop_constraint("fk_users_referred_by", "users", type_="foreignkey")
-    op.drop_column("users", "referred_by_user_id")
-    op.drop_constraint("uq_users_referral_code", "users", type_="unique")
-    op.drop_column("users", "referral_code")
+    with op.batch_alter_table("users") as bop:
+        bop.drop_constraint("fk_users_referred_by", type_="foreignkey")
+        bop.drop_column("referred_by_user_id")
+        bop.drop_constraint("uq_users_referral_code", type_="unique")
+        bop.drop_column("referral_code")