feat: version the hard delete events instead of keeping them only in production

migrations/20260807143052_add_hard_delete_events.sql

@@ -0,0 +1,22 @@
+-- SQLSpec Migration
+-- Version: 20260807143052
+-- Description: add hard delete events
+-- Created: 2026-08-07T14:30:52.000000+00:00
+-- Author: David Riegel <40246197+davidriegel@users.noreply.github.com>
+
+-- name: migrate-20260807143052-up
+
+CREATE EVENT IF NOT EXISTS delete_soft_deleted_clothing
+    ON SCHEDULE EVERY 1 DAY
+    DO DELETE FROM clothing
+       WHERE deleted_at IS NOT NULL AND deleted_at < NOW() - INTERVAL 7 DAY;
+
+CREATE EVENT IF NOT EXISTS delete_soft_deleted_outfits
+    ON SCHEDULE EVERY 1 DAY
+    DO DELETE FROM outfits
+       WHERE deleted_at IS NOT NULL AND deleted_at < NOW() - INTERVAL 7 DAY;
+
+-- name: migrate-20260807143052-down
+
+DROP EVENT IF EXISTS delete_soft_deleted_clothing;
+DROP EVENT IF EXISTS delete_soft_deleted_outfits;

migrations/README.md

@@ -56,3 +56,16 @@ The timestamp is automatically generated in UTC timezone.
 Migrations are applied in chronological order based on their timestamps.
 The database tracks both version and execution order separately to handle
 out-of-order migrations gracefully (e.g., from late-merging branches).
+
+## Scheduled Events
+
+`20260807143052_add_hard_delete_events.sql` purges soft-deleted clothing and
+outfits after 7 days. Two things depend on that window:
+
+- The MySQL event scheduler must be on (`--event-scheduler=ON`, set in both
+  compose files). Without it the rows accumulate silently.
+- The iOS client learns about deletions from `deleted` in the sync response, and
+  a purged row no longer appears there. It falls back to a full, authoritative
+  sync once its cursor is older than 7 days (`SyncManager.shouldPerformFullSync`),
+  which is what keeps the two in step. Shortening the window here without
+  shortening it there would leave clients with items the server has forgotten.