-- ── The teardown ──────────────────────────────────────────────────────────
--
-- Destructive, and run ONLY by an explicit admin purge (MODULE_API.md §2.6).
-- Nothing on the boot path executes this file, and uninstalling your module does
-- not either: removing an operator's data is a second decision they have to make
-- on purpose, offered inside the uninstall flow and confirmed separately.
--
-- It exists because `schema.sql` does. A module that can create tables and
-- cannot drop them leaves an operator with orphaned data and no supported way to
-- remove it — so core refuses to load a module that declares one without the
-- other.
--
-- **Drop in the reverse of creation order**, which this file now actually
-- depends on: `examplegame_clan_members` carries a foreign key into
-- `examplegame_clans`, so dropping the parent first fails on the constraint, and
-- a purge that fails halfway is worse than one that never ran — it leaves
-- exactly the orphaned data this file exists to remove.
-- `IF EXISTS` on every line, so a partially-installed module still tears down.
--
-- **What does NOT belong here: rows you wrote into core's tables.** Notification
-- subscriptions, announce-job legs and settings rows live in core's schema, and
-- a module does not DELETE from core's tables. Core prunes what it knows you
-- registered, because it is the one that knows which registrant owned what.

DROP TABLE IF EXISTS examplegame_clan_members;
DROP TABLE IF EXISTS examplegame_clans;
DROP TABLE IF EXISTS examplegame_world_status;