Per-notifier render pipeline for template bodies

[fxthiry]

Problem

Templates currently define a single body field that is shared across all notifiers. Each notifier then has to render that one body in its native format:

• Mattermost reads body as Markdown-flavored text. **bold**, triple-backtick fences, > quote work as intended.
• Webhook sends body as-is inside the default JSON payload, or lets users override via body_template.
• Email has a separate body_html field that takes precedence, with body as fallback.
• Telegram (added in 1.1.0) uses parse_mode: HTML by default, so Markdown markers from body render as literal characters.

Concretely: if a user writes one template for Mattermost and points a Telegram notifier at the same rule, **Switch:** shows up as **Switch:** in Telegram with ** visible.

Workaround today: set body_template on the Telegram notifier with HTML-friendly Jinja. Documented in 1.1.0 release notes and docs/notifiers.md. It works, but it's per-notifier setup for every user running a multi-notifier config.

Proposed solution

A per-notifier render pipeline instead of per-notifier body fields. Each notifier declares its target format (plain, markdown, html, mrkdwn, etc.) and the engine converts the canonical source body to that format at render time.

One source of truth in the template (probably body_markdown or a neutral tree), N rendered outputs. No schema explosion (body_telegram, body_slack, body_discord would be the wrong abstraction — primitive leak between transport and data layers).

Open questions:

1. What's the canonical source format? Markdown (most common), neutral tree (more work), something else?
2. How do we handle notifier-specific affordances (Mattermost attachment fields, Telegram link previews)? Keep them as per-notifier optional fields — only the body rendering is centralized.
3. Backward compat: users shouldn't have to rewrite their templates on upgrade. Fallback chain: body_<notifier_type> > format-rendered source > body.

Out of scope

• New notifier types (those are separate issues).
• Telegram-specific improvements — those should either ship as small patches or be absorbed once the pipeline lands.

Related

• [Feature]: Telegram alert feature #22 (Telegram notifier, shipped in 1.1.0) — surfaced the limitation in real usage.
• docs/notifiers.md#telegram "Known caveat" section points users here.