Lite: time follow-ups and signing-key storage (#5632 Phase C L3) #6012

Claude posting for Erik Darling.
Part of #5632 (Phase C, Lite, stacked PR after Darling's).

What it does

The Lite side of time follow-ups, and where Lite stores the signing key for signed webhooks. Lite sends the same Standard Webhooks signature from the shared sender. Security: the signing key is sealed at rest the same way Lite stores its existing webhook headers (the bearer token). Find how Lite stores GenericWebhookHeadersJson today (the shared sender reads it at PerformanceMonitor.Notifications/WebhookAlertService.cs:2172) and store the key with the same protection; if Lite stores that value in plain text, say so in the PR body and use the strongest store Lite already has for secrets, and never log or show the key after generation.

Decisions this slice carries (agreed by Erik on 2026-10-16)

• D19 (A), with the decisions Signed webhooks: Standard Webhooks signatures, key rotation, key screens, receiver docs (#5632 Phase C C2) #5998 (D1 to D4) and Time follow-ups: a report sets follow_up_at, Darling opens a new request (#5632 Phase C C12) #6008 (D16, time) carry.

Files to touch

Pointers re-checked on dev at c12233ce3.

• PerformanceMonitor.Notifications/WebhookAlertService.cs:2152-2180 (the shared generic send; signing is added there by Signed webhooks: Standard Webhooks signatures, key rotation, key screens, receiver docs (#5632 Phase C C2) #5998).
• Lite/Windows/NotificationRouteEditDialog.xaml(.cs) and Lite/Windows/NotificationRoutesWindow.xaml(.cs) (route screens) and the Lite notification settings window, for the key screen.
• Lite/Database/DuckDbInvestigationStore.cs:38 (follow-up columns, from Lite: schema step, request events and evidence over DuckDB (#5632 Phase C L1) #6010's schema step).

Depends on

#5998 and #6008, and #6010 for the schema step.

Behaviour to pin

• A Lite send is signed and a receiver recomputing the HMAC accepts it; one changed byte fails.
• The key is stored protected and does not appear in logs or screens after generation.
• A follow-up opens on time with the earlier report in its brief; the 21st pending one and one past 30 days are refused.

Tests

Behaviour pins only, one test per behaviour listed above. No census, roster or source-text test (the #5833 ruling in .github/REVIEW-TRAPS.md).

Notes

• Nothing under deprecated/.
• Nothing under deprecated/.
• At most four parts. If the work needs more, stop and say so in the PR body rather than growing the slice.
• Report the changelog entry in the PR body (the coordinator splices it after the wave; do not edit CHANGELOG.md).