Point alert-settings MCP tools at the Darling Viewer for webhook/SMTP config

[erikdarlingdata]

Closes #2709.

get_alert_settings, update_alert_settings, and the class-level doc comment on DarlingMcpAlertTools all said SMTP/webhook delivery credentials are "managed separately" with no pointer to what that means. As #2709 documents, the mechanism already fully works — the standalone Darling Viewer app's Settings window (Notifications section) writes config.config_notification, its Postgres connection isn't hardcoded to localhost so it can configure a remote headless box, and the running service hot-swaps the change in with no restart. It just wasn't discoverable from the MCP surface an operator (or an agent working on their behalf) would actually consult first.

Change

Extended the two tool descriptions and the class doc comment with a one-clause pointer to the Viewer's Settings window and its remote-connection capability. No behavior change — descriptions only.

Scoped to just the MCP tool descriptions (the issue's option 1) since that's what the issue title names directly and is the highest-leverage single change; didn't touch darling.exe --help (option 2) since every existing help line maps to a real implemented verb and this is a docs-only fix, or add a new doc file (option 3) since the pointer fits cleanly inline.

Test plan

• dotnet build (project + full solution) clean, 0 errors
• No test pins the exact description text (checked), so no test changes needed

🤖 Generated with Claude Code

[claude]

Reviewed. This is a doc-only change to XML doc comments and [Description(...)] attribute strings in DarlingMcpAlertTools.cs — no logic changes.

• Correctness: Verified the added claim against the code — ViewerSettings.cs deliberately does not hardcode the Postgres connection to loopback (see the comment at ViewerSettings.cs:340), so "connects to this store (including remotely, not just localhost)" is accurate.
• Lite/Darling parity: Checked Lite/Mcp/McpAlertTools.cs for a counterpart. Lite's get_alert_settings already reports its smtp group directly (Lite delivers its own email in-process) and Lite has no update_alert_settings at all (settings change only via its own Settings window). The "credentials managed separately, go configure them in the Viewer" situation this PR documents is specific to Darling's architecture (headless service + separate desktop Viewer), so there's no missing counterpart update in Lite — the two apps are correctly staying divergent here, not drifting.
• Tests: Confirmed no test pins the exact description text (grep across Darling.Tests found nothing matching), consistent with the PR's test plan.
• Security/perf: N/A — string-literal-only change, no new inputs, no I/O.

No issues found. LGTM.