feat(templates): rich text editor + inline images in email templates

[shukiv]

What

Adds a rich text editor and inline images to email templates. The template
editor's Body was a plain <textarea>; this swaps it for the existing TipTap
RichTextEditor (the same component the composer uses), so templates get
formatting, links, tables, and inline images — drag-drop or toolbar, already
supported via the @tiptap/extension-image dependency.

Why

Templates could only hold plain text, so any branded/HTML email (signatures,
logos, formatted layouts) had to be rebuilt by hand each time. Reusing the
composer's editor keeps the UX consistent and adds almost no new surface.

How

• lib/template-types — new optional bodyIsHtml flag. Absent/false =
  legacy plain text; true = HTML from the rich editor. Fully backward compatible.
• template-form — <textarea> → RichTextEditor. Legacy plain-text bodies
  are converted with plainTextToSafeHtml on load so they render correctly;
  saved bodies are run through sanitizeEmailHtml. Placeholder insertion now
  lands at the cursor via the editor instead of appending to the end.
• Inline images are stored as base64 data URIs in the template (templates
  have no send context, so no cid is minted — the compose/send path handles
  inlining when the template is applied). Each image is capped at 1 MB to
  protect the localStorage-backed template store.
• email-composer — applying a template branches on bodyIsHtml: HTML
  templates are sanitized and inserted as-is (plain-text compose mode flattens
  them via htmlToPlainText); legacy plain templates keep the previous
  escape-and-wrap behaviour, so existing templates are unaffected.

Backward compatibility

Existing templates have no bodyIsHtml → treated as plain text exactly as before.
They're upgraded to HTML only when re-saved through the new editor.

Notes / follow-ups

• settings.templates.image_too_large was added to all locales with the English
  string; non-English entries need translation.
• Inline images live in localStorage (the template store). The 1 MB/image cap
  keeps a few logos well within budget; this PR does not add server-side image
  hosting for templates.

Test plan

• npm run typecheck, npm run lint, npm run build — all green
• npm run test:translations — 38/38 (locale keys consistent)
• New template: type formatted text, drag in an image → save → re-open shows it
• Apply an HTML template in the composer (rich mode) → formatting + image preserved
• Apply the same template in plain-text compose mode → flattened to text
• Open a pre-existing plain-text template → still renders/edits correctly
• Image > 1 MB → rejected with a toast

[rathlinus]

It says the send path inlines template images but it doesn't. Template images are stored as plain data: URIs and never get a cid or registered for sending, so at send time they go out as raw data: URIs. Gmail and most clients strip these, so recipients see no image.

[shukiv]

Yeah you're right, my bad. Fixed it now: when a template is applied I decode its data: images, push them through the same upload path as dropped images so each gets a real blob + cid, and tag the img with data-cid. The send path then rewrites them to cid: like normal inline images. So they actually reach the recipient now instead of going out as data: URIs.