Dedup check before insert

Duplicate contact records from multiple ingestion runs inflate your list size, distort per-source quality metrics, and cause repeated outreach to the same person — a direct CAN-SPAM and GDPR Art. 5(1)(c) (data minimization) violation. A raw INSERT that relies on a unique constraint exception for dedup handling is not graceful deduplication — it is crash-driven dedup that requires explicit exception handling at every call site or risks silent swallowing of duplicates. CWE-694 (Use of Multiple Resources with Duplicate Identifier) applies when duplicate identity keys are not resolved at the insertion boundary.

Replace raw INSERTs with an explicit upsert pattern that handles the duplicate case intentionally — updating only non-provenance fields on conflict so the original provenance record is preserved.

// Prisma upsert — provenance fields are in `create`, not `update`
await db.contacts.upsert({
  where:  { email: contact.email },
  create: {
    email:       contact.email,
    source_type: contact.source_type,
    source_id:   contact.source_id,
    acquired_at: contact.acquired_at,
  },
  update: {
    last_seen_at: new Date(),  // Only update non-provenance fields
  },
})

-- Raw SQL alternative
INSERT INTO contacts (email, source_type, source_id, acquired_at)
VALUES ($1, $2, $3, $4)
ON CONFLICT (email) DO UPDATE
  SET last_seen_at = NOW();

A unique constraint on email remains required as a database-level safety net, but it should never be the primary dedup mechanism.