fix(alerts): a rule's page doesn't wait for its metric preview (#5485); Send test up top (#5486)

#5485 "A rule's page waits up to 25 s for its metric preview: a cold 24 h
series read from plugin_metrics". Opening "Agent offline" took 25.6 s; a
cold day of one series measured 18.3 s over MCP, a warm one 63 ms. The
pickers still come with the page from plugin_metric_latest; the preview is
its own request (hx-trigger=load), showing "Reading the last day…" until it
lands. Picker swaps no longer read it either.

#5486 "Send test where it can be found": the button moves from inside "What
happens" to the page header beside History, its result under the verdict.

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

docs/core/alerting.md

@@ -81,7 +81,8 @@ whole host", then its mounts, CPU cores, disks and so on, under a heading for
 each kind. A part that reports nothing a rule can watch, such as an interface's
 traffic, isn't listed. The **Metric** list holds only what the picked resource
 reports. Under it, a preview shows the metric's current reading and its last
-24 hours (lowest to highest, with an hourly sparkline), so the threshold can be
+24 hours (lowest to highest, with an hourly sparkline; it loads just after the
+page, since a day of samples can take a while to read), so the threshold can be
 set against real numbers.
 
 ### Rules that cover hosts
@@ -176,7 +177,7 @@ 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,
+**Send test** at the top of 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