AI Webhook Delivery Diagnosis: Reading Arbitrary Receiver Error Bodies

A webhook delivery failure is not a platform error. The HTTP status is the receiver's own response, and the body is the receiver's own words — arbitrary text written by a system this platform does not control.

A 422 whose body names the field it rejected. A 401 whose body says which header was missing. A TLS error string that identifies the exact certificate problem. Reading them and turning them into 'the receiver is rejecting the signature header, so the shared secret on their side is stale' is exactly the work an operator does by hand today.

**What the console already handles**: the deliveries view classifies each attempt with the server's own status (from DELIVERY_STATUSES in the admin crate), counts per status over the whole filtered set, and offers replay. The AI panel adds no counts and takes no action. A diagnosis is a suggestion; the operator still presses Replay themselves.

**Scope**: the grounding query is 'status=failed' — the server's classification, not a client guess. 'retrying' deliveries are excluded because the platform is already handling them. A retry that finally succeeds should not generate a diagnosis that was already obsolete.

**The X-DM-Delivery header as the diagnostic anchor**: every delivery carries X-DM-Delivery — a stable UUID for that (event, endpoint) pair. The diagnosis references this ID so the operator can locate the exact delivery in their receiver's logs. 'The delivery with X-DM-Delivery: <uuid> was rejected with a 422 whose body indicates a missing required field' is a diagnosis the receiver's team can act on immediately.

**When the diagnosis is wrong**: the panel renders the raw error string and response body alongside the AI diagnosis. An operator who disagrees with the diagnosis has the raw material to form their own view. The AI interpretation is a starting point, not the finding.