Update a recipient

Only fields present in the body are changed. type is immutable: including it at all (any value) returns 400. name, default, events, and config each reject an explicit JSON null with 400 — omit the field entirely to leave it unchanged. events, if present, must be a non-empty subset of ["down","up","flapping"]. Changing config.address on a type=email recipient resets it to status=pending and sends a new confirmation message BEST-EFFORT — a send failure here does not fail the request (the response still reflects the committed address change), so a caller that does not see the mail arrive should call POST /recipients/{recipientID}/confirm/resend to retry delivery rather than re-submitting the same PATCH, which sends nothing on an unchanged address (see RecipientPatch). For type=slack (issue #359), config.url and config.channel are each independently optional on PATCH — at least one is required — and config.channel set to null or "" clears the override back to the incoming webhook's own default. PATCHing back the masked config.url from a GET/POST response is rejected with 400 (it fails the same Slack URL grammar check) and leaves the stored URL unchanged. Any URL or channel change on a type=slack recipient cancels its own still-queued, not-yet-claimed (pending/retrying) deliveries, so a destination the caller just replaced never receives one of those. A delivery the Worker has already claimed for dispatch at the moment of the PATCH still runs against the pre-edit destination: a successful attempt is recorded as delivered (overwriting the cancellation), but a failed or retryable attempt leaves the row cancelled, with no attempt count, response code, or response body recorded for that attempt. For type=pagerduty (issue #363), config.integration_key is required when config is present (there is no optional secondary field the way Slack has channel). PATCHing back the masked config.integration_key from a GET/POST response is rejected with 400 (it fails the same key-shape check) and leaves the stored key unchanged. A key change on a type=pagerduty recipient cancels its own still-queued, not-yet-claimed deliveries the same way a Slack URL/channel change does — but never resolves an incident the old key already opened in PagerDuty; only the customer or PagerDuty's own auto-resolve can do that. config applies the same cross-type reserved-key rejection Create does (see that operation's description).