Webhook dispatcher: respect rate limits (429 / Retry-After) instead of counting them as failures

Problem

The webhook dispatcher treats an HTTP 429 like any other failure: it uses up one of the delivery's 5 attempts and, once those are exhausted, counts towards the subscription's 15 consecutive failures that auto-disable it. It also sends several deliveries to the same webhook in parallel (delivery concurrency 8).

Discord limits each webhook to a handful of posts every few seconds. A burst to one Discord channel, such as the ~1,100 government deliveries queued during the PAR-561 pause, can therefore fail permanently and disable the feed it was meant to restore.

Fix

• On 429, wait as long as the response asks (Retry-After / Discord's X-RateLimit-Reset-After) and retry, without using an attempt or counting a subscription failure.
• Defer the subscription's other due deliveries for the same period, so the batch moves on to other webhooks instead of hammering the limited one.
• Send a single webhook's deliveries one at a time, keeping concurrency across webhooks.
• Pace before hitting the limit: when Discord reports X-RateLimit-Remaining: 0 on a success, defer that webhook until the bucket resets.
• Clamp waits to a sane maximum.

Acceptance

• A 429 response never consumes an attempt or increments consecutive_failures, and the delivery is retried after the advertised wait.
• One rate-limited webhook does not delay delivery to other webhooks.
• Tests cover 429 with Retry-After, pre-emptive pacing, and per-webhook sequencing.