Custom request body templates for webhook actions

[zzzmc]

Describe the feature or potential improvement

Describe the feature

Webhook actions currently let users configure the URL and headers, but the
request body is always a fixed JSON envelope (id, timestamp, type,
apiVersion, plus a type-specific payload / prompt / event object).
I'd like to propose an optional custom body template for webhook actions:

• The webhook action config gains an optional bodyTemplate field.
• Empty (default) → existing behavior, unchanged. Fully backward
  compatible, no migration needed.
• Filled → the body is rendered from the template using a safe templating
  engine (e.g. Handlebars) over the same variables already exposed in the
  envelope (payload.*, id, timestamp, type, ...).
• The rendered output is validated as JSON before sending, and
  x-langfuse-signature continues to sign the rendered body, so existing
  signature verification keeps working.
• UI: a template editor with a variable reference, a live preview rendered
  from sample data, and a "send test webhook" button (the final rendered
  request body is currently not visible anywhere, so this would help
  debugging integrations in general).

Why this is needed

Many downstream systems — internal alert gateways, on-prem monitoring
platforms, incident tools with their own event schemas — require a specific
request body format. Today the only options are:

1. deploying a separate adapter/proxy just to translate the payload, or
2. maintaining a fork of the worker.

There is already precedent for format flexibility in the automations
framework: SLACK actions support a messageTemplate, and
GITHUB_DISPATCH wraps the payload in event_type / client_payload. An
optional template for WEBHOOK actions would complete this picture and
remove the need for a translation hop. It would apply uniformly to all
three webhook payload types (monitor-alert, prompt-version,
project-notification).

In our case we're routing Langfuse monitor alerts into an internal alerting
platform that mandates its own body schema, which is what surfaced the
limitation.

Additional information

No response