feat: add send test email for templates and use draft content

[hanamizuki]

Summary

• Add "Send Test Email" feature for templates, matching the existing campaign test email UI and functionality
• Update both template and campaign test email endpoints to accept optional draft fields (subject, body, from, fromName, replyTo), so test emails reflect the current editor content without requiring a save first

Changes

New: Template Send Test Email

• apps/api/src/controllers/Templates.ts — new POST /templates/:id/test endpoint
• apps/api/src/services/TemplateService.ts — sendTest() method with draft content support
• apps/web/src/pages/templates/[id].tsx — Send Test button, dialog, and project member selector

Fix: Use draft content for test emails

• apps/api/src/services/CampaignService.ts — accept optional draft param, use draft fields when present
• apps/api/src/controllers/Campaigns.ts — pass draft fields from request body to service
• apps/web/src/pages/campaigns/[id].tsx — send current editor content with test email request

Test plan

• Open a template, modify subject/body without saving, send test email → verify test email uses the unsaved content
• Open a campaign, modify subject/body without saving, send test email → verify test email uses the unsaved content
• Send test email without any unsaved changes → verify it still works (falls back to DB content)
• Verify test emails can only be sent to project members

🤖 Generated with Claude Code

[driaug]

Why did you add parameters for subject, data etc instead of just passing the ID and using the saved values?

[hanamizuki]

Good question — the intent was to let users send a test email while editing, without having to save first.

The typical flow when iterating on a template/campaign is: tweak subject/body → check how it looks → tweak again. Requiring a save before every test round means the draft state gets committed to the DB before the user is actually happy with it, which felt a bit awkward for a "preview" action. Passing the current editor values lets the test reflect exactly what's on screen.

That said, I totally see the argument for the simpler ID-only approach — it's less surface area on the API and avoids drift between what's saved and what's tested. Happy to go either way:

1. Keep as-is — draft fields stay optional (falls back to saved values when omitted).
2. Split the PR — land the new POST /templates/:id/test endpoint as ID-only first, and discuss the draft-content behavior separately (or drop it entirely).

Let me know which you prefer and I'll adjust.