Fix: resolve webhook retry processor conflict and share retry config (#8)

[Sam-Rytech]

Description

This PR resolves the conflicting retry implementations between webhookRetryScheduler and webhookService.

Changes Made

• Picked webhookRetryProcessor.ts as the single surviving implementation and wired it into index.ts.
• Deleted the conflicting webhookRetryScheduler.ts to remove duplicate sources of truth.
• Extracted backoff configurations and max attempts into a single shared WEBHOOK_RETRY_CONFIG used by webhookService.ts.
• Updated webhook retry SQL queries to properly alias columns (wd.id, ws.callback_url, etc.), avoiding ambiguous references and mapping correctly to the current schema.
• Added a test in webhookRetryProcessor.test.ts asserting that the processor respects the configured backoff delays and max attempts.

Closes #8

[ogazboiz]

the shared retry config part is done right, WEBHOOK_RETRY_CONFIG is exported once from webhookService.ts and consumed there, the duplicate processor file is gone and index.ts is rewired consistently. but the branch does not build or test yet, and there's a design regression to sort:

1. build and test break on a dangling import of a deleted module. src/tests/distributedLock.test.ts:38-39 still does await import("../services/webhookRetryScheduler.js") and tests retryFailedWebhooks at line 53, but this pr deleted that file. npm run build fails with TS2307 (cannot find module ../services/webhookRetryScheduler.js) and the test errors at runtime. remove or rewrite that describe block (the import at ~38-39 and the matching describe("webhookRetryScheduler", ...)), or point it at the new processor.

2. this drops the multi-instance safety that #23 just added. you deleted the lock-protected webhookRetryScheduler.ts (it took a redis lock via cacheService.setNotExists(...:running)) and kept the unprotected webhookRetryProcessor.ts, which runs processRetries() every 10s with no lock. processRetries() in webhookService.ts:290 does a plain SELECT ... LIMIT 100 with no FOR UPDATE SKIP LOCKED, so two instances will grab the same rows and double-send the webhooks. either bring the redis lock back around the processor interval, or add FOR UPDATE SKIP LOCKED and mark rows in-flight.

3. prettier fails on src/services/__tests__/webhookRetryProcessor.test.ts and src/services/webhookService.ts. run npx prettier --write on both.

4. minor: MAX_RETRY_ATTEMPTS is hardcoded to 4 in webhookService.ts, replacing the old derived RETRY_DELAYS_MS.length + 1. correct today (3+1) but it will silently drift if the delays array changes. consider RETRY_DELAYS_MS.length + 1.

get build + test + prettier green and restore the lock semantics and this is close.

if you want to keep contributing, join us on Telegram: https://t.me/+DOylgFv1jyJlNzM0