-- Aufbewahrungsregel fuer routinemaessige Auth-Eintraege (Token-Refresh).
--
-- Seit der Entrauschung landen erfolgreiche Token-Refreshes als
-- `Authentication / LOW`. Diese Kombination traf auf KEINE spezifische Regel
-- (es gab nur `Authentication / CRITICAL`) und fiel damit in die Auffangregel
-- `*` mit 3650 Tagen. Ergebnis: Das Rauschen waere 10 Jahre aufbewahrt worden,
-- echte Logins dagegen nur 2 Jahre - genau verkehrt herum.
--
-- 90 Tage reichen, um einen Refresh-Vorgang im Nachhinein nachzuvollziehen.
-- Idempotent: der Unique-Index (resourceType, sensitivity) verhindert Dubletten.
INSERT INTO `AuditRetentionPolicy`
  (`resourceType`, `sensitivity`, `retentionDays`, `description`, `legalBasis`, `isActive`, `createdAt`, `updatedAt`)
VALUES
  ('Authentication', 'LOW', 90, 'Routine-Auth (stiller Token-Refresh)', 'Betriebsnotwendigkeit / Datenminimierung (DSGVO Art. 5)', 1, NOW(3), NOW(3))
ON DUPLICATE KEY UPDATE
  `retentionDays` = VALUES(`retentionDays`),
  `description`   = VALUES(`description`),
  `legalBasis`    = VALUES(`legalBasis`),
  `updatedAt`     = NOW(3);