Webhook worker silently sends unsigned when the configured signing key resolves to an empty value — should fail closed

Problem/Motivation

McpWebhookWorker::resolveSecret() returns an empty string both when an endpoint declares no secret_key (a legitimate secretless endpoint) and when it declares one whose Key entity is missing or resolves to an empty value (a misconfiguration). The worker only adds X-MCP-Signature when the secret is non-empty — so in the misconfigured case every delivery is sent unsigned, silently voiding an explicitly configured security control.

Observed in production: a file-based Key whose backing file was never created resolved to '' for a month. Every delivery went out with no signature header; nothing logged the degradation. A receiver that verifies signatures rejects them (visible only as 401s in the delivery log); a receiver that treats the signature as optional accepts unsigned posts while believing them governed.

Steps to reproduce

1. Configure a webhook endpoint with secret_key pointing at a Key entity whose value is empty (e.g. a file provider with a missing file).
2. Trigger a subscribed event.
3. The delivery is sent without X-MCP-Signature; no warning or error anywhere distinguishes this from an intentionally secretless endpoint.

Proposed resolution

• Distinguish "no secret_key configured" (send unsigned — intentional) from "secret_key configured but the Key is missing or resolves empty" (fail closed).
• In the failing case, do not send: mark the row terminally (a failed_key status alongside failed_ssrf/failed_redirect from #3613242, or reuse failed with an explicit message naming the key id) and log loudly.
• The #3613242 status-report warning then surfaces the accumulation automatically; optionally hook_requirements() could also pre-flight every enabled endpoint's key resolution so the misconfiguration is visible before any delivery is attempted.