fix: correct constraint name in migration 040 upgrade/downgrade

Migration 040 tried to drop `generations_match_id_fkey`, but on prod
(and any DB upgrading through 039 for the first time) the constraint is
still named `fk_generations_match_id_matches` — the original name from
migration 025 that 039 drops and recreates under the same name.

The mismatch happened because the previous fix (08baebc) queried the dev
DB to resolve `None` constraint names, but dev was already at head, so
the names reflected the post-040 state rather than the pre-040 state.

Fix: use the actual constraint name that exists after 039 runs
(`fk_generations_match_id_matches`) in both upgrade() drop and
downgrade() create, so the migration chain is consistent end-to-end.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Author: vzakharov

alembic/versions/040_fix_generation_fks_to_cascade.py

@@ -23,7 +23,7 @@ def upgrade() -> None:
         op.f("generations_chat_id_fkey"), "generations", type_="foreignkey"
     )
     op.drop_constraint(
-        op.f("generations_match_id_fkey"), "generations", type_="foreignkey"
+        "fk_generations_match_id_matches", "generations", type_="foreignkey"
     )
     op.create_foreign_key(
         op.f("generations_match_id_fkey"),
@@ -52,7 +52,7 @@ def downgrade() -> None:
         "generations_chat_id_fkey", "generations", type_="foreignkey"
     )
     op.create_foreign_key(
-        op.f("generations_match_id_fkey"),
+        "fk_generations_match_id_matches",
         "generations",
         "matches",
         ["match_id"],