Migrar desde Resend

I am moving an email integration from Resend to Bird. Route through it with me.
1. Check what you already have before setting anything up. If Bird's MCP server is connected, use its tools. If the Bird CLI is installed and signed in, use that. Either one is enough, and every step below is an action you take with whichever you have. Only if neither is present, follow https://bird.com/docs/ai/set-up-your-agent.md to set one up and sign me in. Every Bird docs page serves Markdown at its own URL with `.md` appended, so fetch that rather than the HTML.
2. Read https://bird.com/docs/guides/email/migrate/resend.md for the payload, suppression and event mapping, and https://bird.com/docs/guides/email/migrate.md for the order the steps go in.
3. Find and list my Resend usage in this repository before you change anything: the POST /emails and batch call sites and any SDK wrappers around them, the webhook handler and the URL it is registered at, and every domain I send from.
4. Register each of those sending domains with Bird and give me the DNS records to publish, following https://bird.com/docs/guides/email/sending-domains.md. Leave every DNS record my current provider uses exactly as it is: Bird's records are published alongside them and both providers authenticate side by side until I switch traffic. Publishing DNS affects mail for the whole domain, so show me the records and let me publish them.
5. Export the source team's provider suppressions using Resend's documented suppression API or dashboard CSV export. Separately inventory Contacts' global unsubscribe state, topic definitions and each contact's topic subscriptions, segment memberships, and my application's consent evidence. Read this guide's export and mapping section before proposing an import. Show me each source, capture time, page coverage, counts, exceptions, and target-owner mapping. An incomplete or failed export remains unresolved and gives no permission to send. Keep provider suppression provenance separately because Bird's public add creates a manual suppression applying to every category. Show me the proposed restriction and preference changes before importing; do not grant consent, infer a topic mapping, or unblock an address. Reconcile changes since the snapshot before production traffic.
6. Port each single-send and batch call site using this guide's field limits, attachment and batch differences, and retry rules. For webhooks, configure the Bird endpoint's signing secret, webhook-* headers, raw-body verification, and timestamp checks using the maintained Webhooks procedure. Do not assume a header rename completes verification. Preserve source event identity and reason. Map recipient outcomes separately from contact or suppression lifecycle events, and keep both provider handlers while late or in-flight events remain. Read https://bird.com/docs/guides/webhooks.md and https://bird.com/docs/guides/email/events.md.
7. Run my whole integration against Bird's mail sandbox before any production traffic, following https://bird.com/docs/guides/email/testing-sandbox.md. Sandbox sends run the real pipeline without reaching an inbox or touching my sending reputation.
8. Stop and ask me wherever a step needs a decision. Do not point production traffic at Bird until I have seen the sandbox results and replied with the words cut over to Bird. Retiring the Resend path is a separate step that comes later: ask me again and wait for me to reply with the words retire the Resend path. A reply that agrees without naming what it is authorising is not authorisation. Finish by telling me what is left that only a person can do.

Migration owner / routing owner / rollback owner / approver:
Source team / target workspace and region:
Application operation-record location:
Send and batch call sites / SDK wrappers / templates / React rendering:
Category and tracking decisions / attachment and batch adjustments:
Sending domains / side-by-side DNS / separate receiving MX decision:

For each source below: capture time, page/cursor coverage, counts, errors,
source-to-target mapping, imported or preserved counts, and delta watermark:
- Provider suppressions, original reasons, and source references:
- Contacts' global unsubscribe state:
- Topic definitions/defaults and each contact's subscriptions:
- Segment memberships and target contact IDs:
- Application purpose, consent evidence, and timestamps:
Unresolved mappings / excluded cohort / review owner:
Snapshot delta reconciliation before traffic and rollback:

Stable application operation IDs and explicit keys / provider message IDs:
Uncertain outcomes / reconciliation evidence / retry-window decisions:
Sandbox accepted, suppressed, bounce, complaint, and invalid-request evidence:
Representative rendering / attachments / scheduled-message evidence:
Raw-body signature / timestamp / duplicate / delayed / invalid-event evidence:

Eligible pilot cohort / baseline / observation interval / stop thresholds:
Explicit cut over to Bird approval (person, time, and record):
Observed recipient outcomes and event lag:

Rollback stop and routing owner / accepted, in-flight, or uncertain work:
Scheduled cancellation confirmations / eligible unsent operations:
New restriction and preference reconciliation / remaining exceptions:
Late-event consumers / retained DNS and authentication / drain evidence:
Separate retire the Resend path approval (person, time, and record):