fix(migrations): dropping the demo also takes its reset job's interval-change audit rows

0098 deleted the reset job's run rows but not the scheduler_interval rows that changing its interval
wrote; with the job's label gone they rendered as a raw id. The delete now takes every job-targeted
row for it, and a test seeds both kinds below 0098 and upgrades (red on the old filter). The test
has its own file so the removed-features guard can name it.

backend/alembic/versions/0098_drop_demo_account.py

@@ -5,9 +5,9 @@ schedule — goes with its code. Prod held the demo user and 10 whitelist rows.
 
 The upgrade deletes the demo user first (its playlists, states and subscriptions cascade; audit and
 quota rows keep their history with the actor nulled, as for any deleted account), then the traces
-that only the demo code could render: its audit rows (whitelist edits, manual resets, the scheduled
-reset's job runs), the reset job's interval override and its completion notices. Nothing is
-migrated anywhere; the nightly backup holds the rows.
+that only the demo code could render: its audit rows (whitelist edits, manual resets, and every row
+about the reset job — its runs and its interval changes), the reset job's interval override and its
+completion notices. Nothing is migrated anywhere; the nightly backup holds the rows.
 
 The downgrade restores the schema as it stood (0014), empty: the demo user is created lazily on its
 first sign-in, so an empty `demo_whitelist` is the whole of its state.
@@ -26,7 +26,7 @@ def upgrade() -> None:
     op.execute("DELETE FROM users WHERE is_demo")
     op.execute(
         "DELETE FROM audit_log WHERE action IN ('demo_add', 'demo_remove', 'demo_reset')"
-        " OR (action = 'job_run' AND target_id = 'demo_reset')"
+        " OR (target_type = 'job' AND target_id = 'demo_reset')"
     )
     op.execute("DELETE FROM scheduler_settings WHERE job_id = 'demo_reset'")
     op.execute("DELETE FROM notifications WHERE data->>'job_id' = 'demo_reset'")