fix(db): give the anomaly-alert port its own alert_dedup_claims table (was colliding with notification_deliveries)

[kai392]

Summary

src/review/alerts.ts's runAnomalyAlerts writes hourly dedup claims with the shape
(id, project, target_id, notification_key, status) and ON CONFLICT(project, target_id, notification_key) DO NOTHING, but pointed those raw INSERTs at notification_deliveries — whose
real schema (migration 0031) has none of those columns and no such unique constraint. runAnomalyAlerts
has zero callers today, so it hasn't fired, but the moment it's wired to a cron path, every
Discord-notify invocation throws at the first INSERT (table notification_deliveries has no column named project).

• Adds migration 0181_alert_dedup_claims.sql creating a distinctly-named alert_dedup_claims table
  with the real (project, target_id, notification_key) unique index the port needs.
• Points both alerts.ts claim inserts at the new table.

Test plan

• New regression test runs runAnomalyAlerts against the real migrated D1 (createTestEnv, not the mocked claim store the other send-path tests use) — both claim inserts succeed, both rows land in alert_dedup_claims, and a second same-hour run is throttled by the unique constraint (no second Discord POST)
• Non-vacuity verified: reverting the table name back to notification_deliveries reproduces the exact production error (no column named project) and the test fails
• npx vitest run test/unit/alerts.test.ts — 30/30 pass; tsc --noEmit clean

Closes #8901

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[kai392]

Closing to re-file: validate-code failed db:schema-drift:check because the new alert_dedup_claims table needs an entry in scripts/check-schema-drift.ts's RAW_SQL_ONLY_TABLES (it's raw-SQL-only). Cannot push a fix to a one-shot PR; re-filing corrected.