templates

The Templates submodule provides a small, self-contained content library — `campaign_template` rows — that campaigns reference by `template_id` instead of duplicating subject/body text in every campaign. Each template carries a name, an optional slug, an optional description, a subject, an HTML and/or plain-text body, a `content_type` flag ("html" | "text"), and a `status` ("active" | "inactive") used to hide retired templates from pickers without deleting their history.

At send time, CampaignEmailWorkerService only falls back to a template's stored subject/body when the campaign itself has no inline `content_html`/`content_text` or `subject` — the campaign's own fields always take precedence. This lets a campaign either fully own its content or delegate to a shared template, and lets a single template be reused by multiple campaigns simultaneously since the resolution happens per-send rather than by copying the template content into the campaign record at creation time.

CampaignTemplateService also retains a backward-compatible bridge into the Core Mail submodule (`getMailTemplates` / `getSnapshot`), reading from the shared `mail` / `mail_locale` / `mail_var` tables. This lets older integrations that expected campaign templates to live in Core's mail template tables continue to resolve subject/body and variable lists, even though new template authoring happens through `campaign_template`.

Every create, update, and delete on a template publishes a `campaign.template.*` domain event through the Integration submodule's outbox, allowing other parts of the platform (or external systems via webhooks) to react to template lifecycle changes without polling.

The `send-test` endpoint on this submodule is a thin placeholder: it resolves the template by ID and returns an acknowledgement message without actually sending mail, unlike the campaign-level and recipient-list-level test-send endpoints, which do enqueue a real delivery through `CampaignDispatchService`.