fix(notifications): sanitize webhook URLs before logging them

[m4bard]

Fixes #982.

NotificationService.Webhooks.cs logged every outbound provider request at Information level using LogRedaction.RedactText(webhookUrl, LogRedaction.GetSensitiveValuesFromEnvironment()). That helper only replaces values sourced from the process environment, so a webhook URL typed into Settings was never touched and went out whole. The credential sits in the query string for Pushover and Pushbullet and in a path segment for Telegram, Discord and Slack.

The fix

Added LogRedaction.SanitizeWebhookUrl. It keeps scheme, host and port, drops userinfo and the whole query string (the same logic SanitizeUrl already uses), and for the providers whose credential lives in the path, masks just the segment(s) carrying it instead of dropping the whole path:

• api.telegram.org/bot<token>/sendMessage becomes api.telegram.org/bot<redacted>/sendMessage
• discord.com/api/webhooks/<id>/<token> becomes discord.com/api/webhooks/<redacted>/<redacted>
• hooks.slack.com/services/<team>/<bot>/<token> becomes hooks.slack.com/services/<redacted>/<redacted>/<redacted>
• every other host keeps its path and loses its query, same as SanitizeUrl

Wired it into all 25 {WebhookUrl} logging call sites in NotificationService.Webhooks.cs (NTFY, Pushover, Telegram, Pushbullet, Slack, Discord, generic), plus NotificationDiagnostics.LogFailedResponseAsync, replacing both the RedactText calls and the three call sites that were already using the query-only SanitizeUrl.

Also dropped the Pushover form body from its Information log line entirely instead of trying to redact it. That body carries token= and user= as plain form fields, which the existing AggressiveRedact helper cannot catch for the same environment-only reason. I checked the other providers' request bodies (NTFY, Telegram, Pushbullet, Slack, generic) and none of them put a credential in the body, so no change was needed there.

Tests

Added to tests/Features/Application/Security/Redaction/LogRedactionTests.cs:

• One SanitizeWebhookUrl test per provider shape (Telegram, Discord, Slack, Pushover), each checking that the credential is gone and the non-sensitive host/path survives.
• A control case with no credential-shaped content, so the tests cannot pass from a version that just blanks the whole URL.

Added to tests/Features/Application/Security/Redaction/SecurityRedactionTests.cs:

• Three integration-level tests that run the real Pushover, Telegram and Discord code paths in NotificationService.SendNotificationAsync with a credential that is deliberately not an environment variable, capturing the actual formatted log line through a mocked ILogger. If any of those call sites regressed to the old RedactText(webhookUrl, GetSensitiveValuesFromEnvironment()) shape, the credential would appear in the captured log line and these would fail.

Ran the full backend suite: dotnet test tests/Listenarr.Tests.csproj, 3126 passed, 130 skipped, 0 failed, at commit ffdc5e2.

Sequencing

This touches NotificationService.Webhooks.cs, which #754 and #943 are also open against, per the issue's note. Happy to rebase after either lands.

Disclosure: drafted with Claude Code at my direction; I read the cited code at commit ffdc5e2 and reviewed this before posting.