feat(alerts): Send test on a rule checks that its alerts reach someone (#5466)

#5466 "Send test: check a rule's delivery from the rule". A rule's page gets
a Send test button (operator role), and MCP gets send_test_alert. Each sends
a TEST alert for that rule now, by email to everyone who gets alerts and by
webhook. The alert carries the rule's name and condition, at the latest
reading of what it watches; a rule covering hosts uses its first host. The
result for each channel shows under the button, or "Nothing is set up to
send to". Nothing fires, no event is written, and the test is audited as
alert_rule.tested. An alert with no reading now says "has no reading yet"
instead of "is None".

Docs: alerting.md also gains the burst email from #5465 "One email per burst
of alerts".

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/core/alerting.md

@@ -134,6 +134,14 @@ Configured at `/settings/` under SMTP. Settings:
 
 Email is skipped if `smtp.host` is empty.
 
+Alerts that arrive together go out as one email (`core/alert_burst.py`). The
+first alert opens a 30-second window. When it closes, each recipient gets one
+message listing every alert in the window, oldest first, in their own zone,
+with a subject like "[Steward] 3 alerts: 2 firing, 1 resolved". One alert on
+its own keeps its usual email. Every alert's event records whether the email
+went. A burst still waiting when Steward stops is not sent; its alerts stay on
+the Alerts page and in the history.
+
 ### Webhook
 
 Configured at `/settings/` under Webhook. The body is a Jinja2 template rendered to JSON. Content-Type is always `application/json`. If the rendered template is not valid JSON, the delivery is logged as failed and no request is sent.
@@ -154,7 +162,18 @@ Default template (Discord-compatible):
 {"content": "**{{ alert.state }}** — {{ alert.resource }} — {{ alert.rule_name }} ({{ alert.metric }} = {{ alert.value }})"}
 ```
 
-Webhook is skipped if `webhook.url` is empty.
+Webhook is skipped if `webhook.url` is empty. Webhooks are not gathered into
+bursts: each alert posts on its own, at once.
+
+### Send test
+
+**Send test** on a rule's page (operator role), or `send_test_alert` over MCP,
+sends a `TEST` alert for that rule now, by email and webhook, the same way a
+real alert would go. It uses the rule's name and condition and the latest
+reading of what the rule watches. A rule that covers hosts uses its first
+host. Each channel's result shows under the button. Nothing fires, the rule's
+history doesn't change, and the test is recorded in the audit log as
+`alert_rule.tested`.
 
 ---
 

docs/core/mcp.md

@@ -86,7 +86,7 @@ Each role includes the tools of the roles above it in this list.
 |---|---|
 | Automation | `run_playbook`, `cancel_ansible_run`, `create_schedule`, `update_schedule`, `delete_schedule` |
 | Monitors | `create_monitor`, `update_monitor`, `set_monitor_enabled` |
-| Alerts | `create_alert_rule`, `update_alert_rule`, `acknowledge_alert`, `create_maintenance_window`, `end_maintenance_window` |
+| Alerts | `create_alert_rule`, `update_alert_rule`, `acknowledge_alert`, `send_test_alert`, `create_maintenance_window`, `end_maintenance_window` |
 
 ### Admin: destructive and remediation