feat(mail): consolidate outbound email onto one mail module and send path

[klaudia-blazyczek-blurify]

Summary

Consolidates all outbound email onto one mail module and one send path: callers hand MAIL_DISPATCH a { key, data } template, it enqueues onto mail-send, and the worker resolves the recipient, renders once, and sends off the request path. Breaking: SEND_EMAIL and NOTIFICATION_DELIVERY_ADAPTER are removed in favour of EMAIL_SENDER, and the renderer contract changes shape.

Why

Email left the platform three different ways - the identity OTP hook rendered and sent inside the request, compliance/rg.service rendered and swallowed the error in a warn log, and the notifications module carried a sendEmail: boolean flag and mailed the in-app notification's English body. None of the three had a delivery guarantee; several template keys never saw the recipient's language and formatted dates as en-GB; rendering ran on the request path. The two ports it went through (SEND_EMAIL, NOTIFICATION_DELIVERY_ADAPTER) both existed only to move an email, with different argument shapes, and an operator had to bind both.

Alternatives considered

• Reuse NOTIFICATION_DELIVERY_ADAPTER under a new argument shape - rejected: a silent change of contract under a familiar name; a compile error on a renamed port is the safer break.
• Bind the send path in identity or notifications - rejected: notifications depends on identity and identity needs to send, so a mail binding in either closes a load-order cycle. The mail module declares no dependsOn and consumers resolve MAIL_DISPATCH lazily.
• Keep sendEmail: boolean on the notification input - rejected: a flag can't carry the template key or its data, which is why four mails used to go out as the notification's plain English body.
• Change the broker to ack only after a successful enqueue - rejected here: it touches every subscriber on the platform. Interim guard is a short enqueue-retry; the durable fix (an outbox row in the caller's transaction) is deferred.

Risks

• Breaking: SEND_EMAIL / NOTIFICATION_DELIVERY_ADAPTER removed (bind EMAIL_SENDER); the notification-delivery port loses its email method; EMAIL_TEMPLATE_RENDERER.render now takes the { key, data } template whole and returns { subject, html, text }; createAuth swaps sendEmail / templateRenderer / getUserLanguage for one dispatchOtpMail hook. ADR-0038 and docs/adapters/mail.md cover the move.
• Rollout: the notifications-dispatch and kyc-resubmission-notify job payload shapes changed (mail template instead of a bool; eventId now carried). The new schemas accept the previous release's shape on a rolling redeploy - the in-app notification still lands and the mail is skipped rather than dead-lettering.
• New boot dependency: the mail-send payload is authenticated-encrypted with AUTH_SECRET, so the mail plugin now asserts AUTH_SECRET is at least 32 characters at register time.
• Infra: the Redis service in docker-compose.yml and the consumer template gets an fsync'd append-only journal and a volume so queued work survives a restart. A dedicated queue instance is deferred.
• Deferred: the ack gap between an event handler and its enqueue (interim retry only), and a dedicated Redis instance for the queue - both tracked for a follow-up.

[marek-chmielowski-blurify]

Automated review findings (see inline comments for the four tied to this diff). One additional finding has no line in this diff to anchor to:

packages/core/generators/src/config.ts:373 — the adapter scaffold generator's token-choice list still offers the deleted SEND_EMAIL and NOTIFICATION_DELIVERY_ADAPTER tokens and wasn't updated to offer the new EMAIL_SENDER token. A consumer who runs the generator and picks either old token gets a generated overlay plugin importing a token/type this PR deletes (packages/core/src/contracts/adapters/email.ts and notification.ts are both removed) — guaranteed compile failure with no working replacement offered.

[zaxovaiko]

Re-checked the fixes, the four earlier threads look good. Three things left, mostly about where the copy lives and who can change it.

[zaxovaiko]

Hm, the English copy is still baked in here - the rg fix moved it out of rg.service.ts into PLAIN_EMAIL_TEMPLATES, so it moved rather than went away, and locale still only reaches Intl for the date. I'm fine with the default renderer shipping English, what I'm missing is the configurable part: today the only way for a consumer to change a subject or a body is to write a TS overlay and redeploy. We want the operator to edit the templates per key and per locale from the back office, the way betfeel does it - so an email_template table (key + locale + subject + body), admin CRUD, and a renderer that reads it and falls back to renderDefaultEmail. Doesn't have to be this PR, but let's have the ticket before we call the mail module done.

Also, should this copy sit in adapters/email-template.ts at all? It's the published contract surface, so every consumer ships English strings it never renders - mail/default-email-template-renderer.ts feels like the better home.

[zaxovaiko]

The in-app side is in worse shape than the mail one - title and body are hardcoded English here with no port at all, so a consumer can't override them even with an overlay. The same applies to buildKycResubmissionNotification and the rg.limit.set copy further down (describeLimitValue still returns ${minutes} minutes, plus no prior limit). Can we give the in-app notifications the same seam as the mail templates, so both channels render through something the operator controls? Fine as a follow-up, but I'd keep it in the same ticket as the email templates.