suppression

The Suppression submodule maintains `campaign_suppression`, a single global list of email addresses that must never receive campaign mail, regardless of which recipient list they appear on. Every campaign send performs a bulk suppression check (`CampaignSuppressionService.bulkCheck`) against the full audience before creating message rows, so a suppressed address is skipped at enqueue time, not silently dropped later — the corresponding `campaign_message` row is created with `status: skipped` so the campaign's totals stay accurate.

Each suppression entry carries a `reason` — `manual`, `bounce`, `complaint`, `unsubscribe`, or `invalid` — plus a free-text `note`, an optional `source` string, and optional `campaign_id`/`message_id` back-references to the send that triggered it. Adding an entry has a side effect beyond the suppression table itself: `CampaignSuppressionService.create` also updates any matching `campaign_recipient` rows to `status: bounced` (when `reason` is "bounce") or `status: suppressed` (for every other reason), keeping the recipient-level status consistent with the suppression-level record. The unsubscribe flow (in the Unsubscribes submodule) and any future bounce/complaint webhook handler both funnel through this same `create` method.

Removing a suppression entry — whether by bulk delete or by single-ID delete — is the literal inverse: it deletes the suppression row(s) and resets the corresponding `campaign_recipient` rows back to `status: active`, effectively re-admitting that address into future sends. There is no separate "reactivate" endpoint; deleting the suppression record is how an operator manually un-suppresses an address.

`GET /campaign/suppression/stats` returns a reason-by-reason breakdown (total, plus counts for unsubscribe/bounce/complaint/manual/invalid), which the dashboard surfaces to give operators visibility into why their suppression list is growing — a spike in `bounce` typically signals a deliverability problem distinct from a spike in `unsubscribe`.