Backend: Webhook retry mechanism with exponential backoff

[KuchiMercy]

Summary

The webhook controller and entity exist but there is no retry logic for failed webhook deliveries. Third-party integrations relying on webhooks need reliable delivery guarantees.

Requirements

• Implement a retry queue for failed webhook deliveries
• Use exponential backoff: 1s, 2s, 4s, 8s, 16s (5 retries max)
• Track delivery status per webhook event: pending, delivered, retrying, failed
• Store delivery attempts with response status codes and error messages
• Move permanently failed webhooks (5 retries exhausted) to a dead-letter log
• Add an admin endpoint to view failed webhooks and manually retry them
• Add a webhook health check endpoint showing delivery success rate

Acceptance Criteria

• Failed webhook deliveries are automatically retried up to 5 times
• Retry intervals follow exponential backoff pattern
• Each delivery attempt is logged with status code and response body
• Permanently failed webhooks are visible in the admin panel
• Admin can manually trigger a retry on a failed webhook
• Webhook health endpoint returns delivery success/failure rates
• Webhook delivery does not block the main escrow transaction flow (async)

Context

• Webhook controller: apps/backend/src/modules/webhook/webhook.controller.ts
• Webhook entity: apps/backend/src/modules/webhook/webhook.entity.ts
• Webhook service: apps/backend/src/services/webhook/webhook.service.ts
• NestJS schedule module is already configured for cron jobs

Points: 150