Send order, verification and password-reset emails

Context: this project is the online store "Thread & Needle", a fashion e-commerce store selling women's and men's clothing, shoes and accessories in United States. The store's domain is threadandneedle.com. It uses Next.js, TypeScript, PostgreSQL with Drizzle (local database shop_local), Zod and Auth.js. Customer accounts exist (Episode 11) and test payments mark orders paid through a webhook (Episode 13).

Goal: send transactional email (emails triggered by something a customer did) with Resend. Before coding, read Resend's official documentation for its Node SDK and for Next.js, because details change.

Plan first: show me your plan (files, tables, templates, environment variable names) and wait for my OK before changing anything. Explain SPF, DKIM and DMARC in two plain sentences each.

Tasks, after I approve:
1. Walk me through the Resend setup one step at a time: create an API key with the narrowest permission available, add the domain threadandneedle.com (a sending subdomain such as mail.threadandneedle.com is fine), and add the DNS records Resend shows me. Tell me exactly which records to copy and where. Do not guess record values; I will paste what Resend shows. Show me how to check that the domain says Verified. Suggest a basic DMARC record too.
2. Put the key in .env.local only (RESEND_API_KEY, EMAIL_FROM) and add just the names to .env.example. Never print, log or commit the key.
3. Create one small email module with a single send function that always sends both an HTML and a plain-text version, uses a fixed From address on my verified domain, and never throws into the caller: failures are logged without personal data.
4. Build simple, mobile-friendly HTML templates plus plain-text versions for: order confirmation (order number, items, totals, shipping address, link to the order); shipping update (carrier and tracking link, ready to be called from the admin in Episode 16); email address verification; password reset.
5. Send the order confirmation from the payment webhook after an order becomes paid. Use an email_log table with a unique key per order and email type so a repeated webhook never sends a second copy. An email failure must never make the webhook fail.
6. Verification and reset links: use a long random token, store only its hash, set an expiry (reset: short, verification: longer), allow one use, and invalidate old tokens when a new one is made. The reset form must give the same answer whether or not the email exists, so nobody can find out who has an account.
7. Abuse care: rate-limit verification and reset requests per email address and per IP address. Escape every customer-provided value inside templates.
8. Development mode: if there is no API key, print the email to the terminal instead of sending it, but only when NODE_ENV is development.

Security rules: no secrets in code or chat; do not put tokens or full addresses in logs; send nothing marketing-related from these templates.

Verify yourself and show results: Vitest tests for token expiry, one-time use and the duplicate-send guard; then send each of the four emails to my test address and tell me what to look for. Run the type check and linter.

Commit to a branch named feature/transactional-email with a clear message.

Report back in this format: 1) What was done. 2) What I should check in my inbox and the Resend dashboard. 3) Anything that needs my decision.

Review the prompt, then copy it. Never paste real passwords or API keys into a chat.