fix: don't let token-bearing emails linger in the durable store

[andregoepel]

Closes #55 (F6 — token-bearing email bodies & recipient PII persisted in the Wolverine outbox).

What

Identity emails (confirmation / password-reset links and codes) are sent through the Wolverine durable outbox/inbox, so each MailMessage body — a short-lived auth token plus the recipient's email — is persisted in Postgres. Successful sends are removed promptly, but failed messages were dead-lettered and lingered indefinitely, and a stuck message could sit across an outage. This bounds that:

• [DeliverWithin] on MailMessage — an undelivered message is discarded after 1 hour (far beyond normal sub-second delivery, so the happy path is unaffected) instead of persisting as a token-bearing row.
• Handler Configure(HandlerChain) convention — on failure, retry a few times (100ms / 1s / 5s) then Discard rather than move the body to the dead-letter table.

Net: no MailMessage body outlives its usefulness or accumulates in dead letters; successful sends were already auto-removed.

Trade-off

Discarding on permanent failure means a failing SMTP config silently drops identity emails (Wolverine still logs each discard) rather than leaving dead-letter rows to inspect. That's the right call for token/PII payloads, and the synchronous admin Email Settings → Send test path (which surfaces SMTP errors directly in the UI, bypassing the bus) remains the way to diagnose SMTP problems.

Scope note

This is the in-code half of the remediation. Restricting DB/backup access and overall retention are operational; the token TTL/single-use itself lives in marten-identity.

Design notes

The Wolverine 6.16 APIs used ([DeliverWithin(seconds)], chain.OnAnyException().RetryWithCooldown(...).Then.Discard(), the static Configure(HandlerChain) convention) were verified against the package's own API surface and a compile probe before use.

Tests

MailMessageDurabilityTests guards that the [DeliverWithin] cap and the Configure convention method stay present and correctly shaped — these are framework-driven controls, so a silent removal would re-open the issue with no compile error. Existing handler tests unchanged.

Verification

• dotnet build -c Release — 0 errors.
• dotnet test -c Release — 80/80 passing (3 new).