Custom alerts: ship starter rule templates + list_custom_alert_templates MCP tool (#3285 Component 7) #3325

Part of the custom-alerting feature (#3285), plan Component 7. This is #3282's Q2 answer: ship starter rule TEMPLATES over new hardcoded evaluators, so the collected-but-unalerted signals get sensible off-the-shelf coverage that also generalizes to signals nobody has named yet.

Deliver

1. A code-defined set of validated starter CustomAlertRuleDefinition templates ({key, name, description, definition}), covering the PG signals No alert requires its condition to PERSIST: real fire/resolve pairs 55-87 seconds apart on both engines — and it is not the re-fire class closed seven times #3282 names (autovacuum activity/slope, replication lag, connection/session saturation, table bloat, storage growth) plus a few obvious SQL Server ones (signal-wait %, sustained blocking, long-running query, tempdb pressure). Each maps to a real compose-catalog measure with sensible starter thresholds + hysteresis.
2. A REQUIRED drift-guard test (mirroring ViewTemplatesTests for custom views): every template validates against the live rule-validator + MeasureCatalog on every build, so a template referencing a measure that drifts out of the catalog fails the build rather than shipping dead.
3. A read-only list_custom_alert_templates MCP tool so a client can browse the set and create_custom_alert_rule from one (the web editor, a later slice, will also surface them).

Notes

• Adding the MCP tool trips the five custom-alert inventory pins (census, ratchet, ExcludedToolNames + its sorted array, the DarlingMcpCustomAlertToolsTests surface pin) — all must be updated and the FULL Darling.Tests + Lite.Tests suites run.
• Templates are a starting point users copy + tune, not a hardcoded evaluator; scope defaults to all and thresholds are documented per template.