Lite's MCP reports 4 alert groups to Darling's 48, and cannot write any of them

[erikdarlingdata]

Surfaced by the review on #2392, which correctly declined to fix it there — it is much larger than the file-growth knobs that PR was about, and #2392 does not make it worse.

Lite's McpAlertTools.GetAlertSettings reports four groups:

cpu   blocking   deadlocks   smtp

Darling's update_alert_settings alone dispatches on 48 top-level and nested keys, and its get_alert_settings reports the matching read shape. Lite has no update_alert_settings tool at all.

So on Lite, an MCP client cannot read whether tempdb-space, low-disk, PVS, long-running-query, long-running-job, failed-job, database-state, file-growth, analysis, connection, or AG alerting is even on — and cannot change any setting, including the four it can read.

Two things make this worth fixing rather than accepting:

The engine is shared. PerformanceMonitor.Alerting evaluates the same alerts on both SKUs against IAlertEngineSettings, and AppAlertEngineSettings already projects every one of Lite's App.Alert* statics onto that interface. The gap is purely the MCP surface — nothing about Lite's alerting is actually narrower.

And #2391 was this same shape at smaller scale: a knob wired end to end with no way to reach it, where the workaround was hand-editing the config. Here the workaround is hand-editing settings.json, which is worse on Lite than on Darling because there is no store-side plane to fall back to.

There is one real design question to settle first, which is likely why this never happened. Darling's tools write to config_alert_settings, and the service picks the change up through StoreConfigProvider.ApplyToConfig — a live reload with no restart. Lite has no equivalent: its settings live in App.Alert* statics that the Settings window writes to settings.json, and an MCP write would have to mutate those statics AND persist them AND stay coherent with a Settings window that may be open with stale values loaded. SaveAlertSettings reads its controls, not the statics, so it would happily overwrite an MCP-applied change on the next Save.

Reasonable scopes, smallest first:

1. Read-only parity. Extend get_alert_settings to report every group Darling reports. No coherency problem at all, and it is most of the practical value — an agent triaging a Lite instance can at least see the configuration.
2. Read-only parity plus a narrow update. Add update_alert_settings but have it reject while the Settings window is open, sidestepping the stale-overwrite case rather than solving it.
3. Full parity. Give Lite a change-notification seam so the Settings window reloads on an external write. Correct, and clearly the largest.

Note McpAlertSettingsKeyTests pins the wire key names Lite already emits, so a read-only expansion needs those assertions extended, not rewritten.

[erikdarlingdata]

Fixed on dev by #2410. Lite's get_alert_settings now reports 13 further groups — poison_wait, long_running_query, tempdb_space, low_disk, pvs, file_growth, long_running_job, failed_job, database_state, cooldown_minutes, excluded_databases, delivery, analysis — in Darling's spellings and document order, resolved from BuildAlertSettingsPayload rather than guessed.

Two spellings would have been wrong if guessed, which is the argument for reading the other side rather than inferring it: low_disk nests the critical floors as critical_free_percent/critical_free_gb, dropping the "disk" that Lite's own App.AlertDiskCriticalFree* statics carry; and delivery.mode is a second value-level translation alongside cpu.mode, though it is the one case where ToString() is correct rather than a mapping, since AlertNotificationMode is the shared enum and Darling's store holds literally its ToString().

self_alerts is deliberately not emitted. It is genuinely Darling-only: AppAlertEngineSettings returns hardcoded constants for three of its four members because Lite has no headless store volume or fleet collection loop, and has no member at all for store_job_cadence_warn_percent. Emitting constants under knob-shaped names would advertise tunability Lite does not have.

Scope 1 only, as planned — no update_alert_settings for Lite. The coherency problem is unchanged and still needs a design decision: Lite's settings live in App.Alert* statics, and SaveAlertSettings reads its CONTROLS rather than those statics, so an open Settings window would silently overwrite an MCP-applied change. That remains the blocker for scopes 2 and 3.

Two adjacent defects surfaced while matching the two payloads, both verified and split out to #2415 rather than folded in here — they are Darling-side and this issue is Lite-side.