Fold the custom-alert follow-ups (tag scope, range operators, last-fired) into the changelog

CHANGELOG.md

@@ -10,7 +10,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 ### Added
 
 - **A mute rule that has outlived its reason now reports itself** ([#3306]) - a mute is a deliberate blind spot in a monitoring tool, and nothing surfaced that one existed, how old it was, or whether it would ever expire; the only way to find one was to already suspect it and call `get_mute_rules`. So a rule created to stop a false-positive flood keeps suppressing the alert after the fix ships, and the symptom is silence rather than a number going the wrong way - the Retention Held pattern one surface over, and harder to notice for exactly that reason. A new fleet-level service self-alert reports a rule that is enabled, has no expiry, and was created longer ago than the longest expiry the mute dialog itself offers, judged on that conjunction rather than on permanence alone, which the dialog offers on purpose. Severity follows blast radius: a rule that constrains nothing suppresses EVERY alert on the store, so the fleet reads healthy for want of anything being reported, and that reads Critical. Nothing is un-muted automatically - a silent expiry floods the delivery channel the rule was usually created to protect - so the alert states the rules, their ages and their reasons and leaves the decision with the operator, while the triage link drills straight into the rule list and the week of alert history a muted alert is still recorded in. No blanket mute can suppress it: a rule that constrains nothing matches every alert including this one, so honouring such a mute would let the condition suppress the only report of its own subject. It re-states itself once a day rather than on the shared alert cooldown, which on the shipped defaults would have posted every fifteen minutes about a fact that changes on a scale of days.
-- **User-authored custom alert rules** ([#3285]) - a threshold alert on any compose-catalog measure, the companion to the custom notebooks: choose a source, measure, aggregate and window, a comparison with Warning/Critical thresholds, N-sample hysteresis and a scope of all servers or a chosen few, and the service evaluates it on its own sweep and delivers through the existing plumbing (cooldown, mute rules, Summary/per-event, email and webhooks) - for SQL Server and PostgreSQL metrics alike. Rules are authored over MCP (`create_custom_alert_rule` / `update` / `delete` / `get` / `list` / `validate_custom_alert_rule`, plus `test_custom_alert_rule` to see a rule's current value and would-fire verdict on each in-scope server without delivering, and `list_custom_alert_templates` for a starter set covering common PostgreSQL and SQL Server signals such as autovacuum backlog, replication lag, connection saturation and blocking); the compose catalog gained the PostgreSQL measures for all 20 PG collector tables, gated so a measure only offers on the server types that collect it, which makes PostgreSQL targets both alertable and chartable. Notifications show the rule's name rather than an internal id; a rule that no longer compiles or can never fire (scoped to no monitored server, or an always-NULL measure) is surfaced as one aggregated service self-health alert; and disabling or deleting a rule force-resolves any open incident. This release ships the evaluation engine, the MCP authoring surface, and a visual web editor in the viewer (the Scalar compose picker with inline validation, a live per-server would-fire preview, start-from-template, and a "create alert from this panel" action).
+- **User-authored custom alert rules** ([#3285]) - a threshold alert on any compose-catalog measure, the companion to the custom notebooks: choose a source, measure, aggregate and window, a comparison with Warning/Critical thresholds or a range (within or outside a band), N-sample hysteresis and a scope of all servers, a chosen few, or a fleet tag, and the service evaluates it on its own sweep and delivers through the existing plumbing (cooldown, mute rules, Summary/per-event, email and webhooks) - for SQL Server and PostgreSQL metrics alike. Rules are authored over MCP (`create_custom_alert_rule` / `update` / `delete` / `get` / `list` / `validate_custom_alert_rule`, plus `test_custom_alert_rule` to see a rule's current value and would-fire verdict on each in-scope server without delivering, and `list_custom_alert_templates` for a starter set covering common PostgreSQL and SQL Server signals such as autovacuum backlog, replication lag, connection saturation and blocking); the compose catalog gained the PostgreSQL measures for all 20 PG collector tables, gated so a measure only offers on the server types that collect it, which makes PostgreSQL targets both alertable and chartable. Notifications show the rule's name rather than an internal id; a rule that no longer compiles or can never fire (scoped to no monitored server, or an always-NULL measure) is surfaced as one aggregated service self-health alert; and disabling or deleting a rule force-resolves any open incident. This release ships the evaluation engine, the MCP authoring surface, and a visual web editor in the viewer (the Scalar compose picker with inline validation, a live per-server would-fire preview, start-from-template, and a "create alert from this panel" action); the rule list shows when each rule last fired.
 
 ### Fixed