feat: add message_id to Email and webhook EmailBody types

[cpenned]

Summary

Adds message_id typing to match the Resend API and Node.js SDK:

• types::Email — message_id is now deserialized from GET /emails/:id and list responses
• events::EmailBody — message_id is now available on all email webhook event payloads (not only email.received)

The field was previously only exposed on inbound emails (InboundEmail) and nested inside the Received webhook struct. It is now a top-level field on EmailBody, so consumers can access event.data.message_id consistently across all email webhook types.

Changes

• Added message_id: String to emails::types::Email
• Added message_id: String to events::EmailBody
• Removed duplicate message_id from events::Received (still flattened via EmailBody)
• Updated deserialization tests and webhook fixture JSON

Test plan

• cargo test --lib --no-default-features --features rustls-tls deserialize
• cargo test --lib --no-default-features --features rustls-tls events::test::email_

  

---

Summary by cubic

Expose the RFC Message-ID on sent emails and all email webhook events for consistent access across the API. Aligns with the Resend API and Node.js SDK.

• New Features

  • types::Email: added message_id from GET /emails/:id and list responses.
  • events::EmailBody: added top-level message_id on all email webhook payloads.

• Migration

  • events::Received.message_id was removed. Use EmailBody.message_id instead (e.g., event.data.message_id).

^{Written for commit e1ab13e. Summary will update on new commits.}

[cubic-dev-ai]

No issues found across 2 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

<sub>Auto-approved: Adds a required message_id field to Email and EmailBody types alongside updated tests and fixtures. The change is type-only for API alignment, has no business logic or infrastructure impact, and is covered by existing tests.

Re-trigger cubic</sub>

[hermesresend]

LGTM — clean addition with solid test coverage across all event fixtures. One non-blocking note: message_id is a required String on Email and EmailBody, so deserialization will hard-fail on any payload that omits it (e.g. older stored events or replayed webhooks). If there's any chance the API omits it for legacy data, Option<String> with #[serde(default)] would be safer — matches the nullable approach in the .NET SDK. Fine as-is if the API guarantees the field.