Webhook worker follows redirects: a 301 turns the signed POST into a GET and deliveries fail permanently with no hint

Problem/Motivation

McpWebhookWorker sends deliveries with Guzzle's default redirect behavior. When a configured endpoint URL answers with a 301/302 (the classic case: apex domain canonicalizing to www at the edge), Guzzle follows the redirect and — per RFC-compliant client behavior — re-issues the request as a GET with no body. The receiver at the redirect target correctly refuses it (405 or similar), the delivery walks the whole retry/backoff ladder, and after MAX_ATTEMPTS the row lands in permanent failed.

Nothing anywhere mentions the redirect: last_response_code records the terminal 405 from the wrong request, and the operator is left staring at a receiver that answers POSTs fine when tested by hand. Observed in production: 1968 of 1968 deliveries over a month failed exactly this way because the endpoint was configured with the apex URL.

A signed webhook cannot survive a redirect hop. The method gets rewritten, the HMAC-signed body is dropped, and the request that arrives is not the request that was signed. Receivers must be addressed by their exact URL.

Steps to reproduce

1. Configure a webhook endpoint whose URL 301-redirects (e.g. https://example.com/hook → https://www.example.com/hook).
2. Trigger any subscribed event.
3. The delivery fails with the target's 405/4xx, retries five times over ~11 hours, then permanently fails. No log or delivery-row field ever mentions the redirect.

Proposed resolution

• Send with 'allow_redirects' => FALSE. The worker should never follow a redirect for a signed delivery.
• Treat any 3xx response as a delivery failure and record the Location header in last_response_body, so the delivery log says "endpoint redirects to X — configure the exact receiver URL" instead of a bare 405.

Related hardening noticed while diagnosing (split into separate issues if preferred)

• A row claimed in_progress by a worker that dies before writing a result is stranded forever — the cron re-enqueue scan only picks up pending. A stale-claim sweep (reset to pending after a claim TTL) would make the pipeline self-healing.
• Permanent failures are invisible: nothing surfaces the count of failed delivery rows. A hook_requirements() warning (and/or dashboard figure) when permanent failures accumulate would have turned a month of silence into a status-report red flag.