feat(admin): add DLQ for failed Soroban transactions with retry endpoint

[starboytiimz]

closes #152

Adds a Dead Letter Queue for Soroban transactions that fail terminally during escrow lock submission, with an admin-only endpoint to review and manually retry them.

Changes
src/models/DlqEntry.ts (new) — Mongoose schema/model for DLQ entries: payload, errorReason, retryCount, status (pending/retried/resolved), timestamps
src/services/dlqService.ts (new) — DlqService: addEntry, listEntries (paginated), retryEntry (resubmits via stellarService.submitEscrowLock, dynamic import to avoid circular dependency)
src/controllers/dlqController.ts (new) — DlqController bridging HTTP to DlqService, uses the standard sendSuccess response envelope
src/routes/adminRoutes.ts (modified) — added GET /api/v1/admin/dlq and POST /api/v1/admin/dlq/:id/retry, protected by existing router-level authenticate + requireRole(UserRole.ADMIN) middleware
src/services/stellarService.ts (modified) — on terminal Soroban submission failure in submitEscrowLock, pushes payload + error to DLQ before throwing AppError; DLQ write failure is caught and logged, never masks the original error
Architecture
Controller -> Service -> Model layering enforced throughout
Routes versioned under /api/v1 (confirmed: app.ts mounts /api, routes/index.ts mounts /v1/admin, adminRoutes.ts mounts /dlq)
No mock data — all reads/writes go through MongoDB via Mongoose
Known limitation

retryEntry calls submitEscrowLock again on the same payload. If that retry also fails, stellarService's failure path creates a new DLQ entry rather than updating the original, so repeated failures on the same transaction produce duplicate DLQ rows instead of one entry with an incrementing history. Flagging for follow-up, not fixed in this PR.

Pre-existing issues

Local npm install fails on main due to @stryker-mutator/core@^7.3.1 and @stryker-mutator/typescript-checker@^7.3.1 no longer resolving on the npm registry. This blocks local tsc --noEmit verification and is unrelated to this change; confirmed present in HEAD:package.json before any changes here.

Security / Rollback
Both DLQ endpoints require admin auth (authenticate + requireRole(UserRole.ADMIN)), enforced at router level
Retry path reuses existing submitEscrowLock validation, no bypass of transaction validation on replay
Rollback: revert this branch's commits; DlqEntry is a new collection, no migration of existing data to reverse

[drips-wave]

@starboytiimz Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[Tybravo]

@starboytiimz
Well done work and thank you for contributing