-- Drops the two FK constraints that tie `media` to the LOCAL `hxa.city`
-- referential (`city_id` and `suggested_city_id`).
--
-- Why
-- ---
-- The administrative geo-resolution (`CALL geo_v2.locate(lat, lng)`, driven by
-- `PUT /admin/media/{hex}/geo` and the upload pipeline) returns ids from the
-- `geo_v2.city` referential, whose id space is DISJOINT from `hxa.city`. In
-- production the two referentials live on SEPARATE database servers, so a
-- cross-server FK cannot be enforced at all — and even in the shared dev DB the
-- constraint rejected every resolved city (id absent from `hxa.city`), which
-- made `updateGeoIds` throw and silently drop the whole geo update (country /
-- region / subregion included, since all four columns move in one UPDATE).
--
-- The relationship between a media and its city is now reconciled through
-- Meilisearch (the `cities` index, resolved by CitySummaryResolver /
-- MediaLocationBlocksLoader) rather than a SQL foreign key.
--
-- The backing KEY indexes (`fk_media_city`, `fk_media_city_suggested`) are
-- LEFT IN PLACE: dropping a foreign key does not drop its index, and the
-- indexes still back "media in city X" lookups on the SQL side. `country_id` /
-- `region_id` / `subregion_id` already carry no FK, so no other constraint
-- guards the geo cascade after this change.

ALTER TABLE `media`
    DROP FOREIGN KEY `fk_media_city`,
    DROP FOREIGN KEY `fk_media_city_suggested`;
