feat: Resilient background job retry and monitoring (#130)

[zacharylyonstx]

Summary

Implements bounty #130 — Resilient background job retry & monitoring system.

Backend

• JobExecution model — Tracks every background job with status (PENDING → RUNNING → SUCCESS/FAILED/RETRYING → DEAD), attempt counts, error capture, timing, and retry scheduling
• Exponential backoff retry engine — execute_with_retry() wraps any callable with configurable max retries, exponential backoff (base × 2^attempt) with ±25% jitter, and a 10-minute ceiling
• @resilient_job decorator — Drop-in for APScheduler jobs: just decorate and get full retry + tracking for free
• Redis status cache — Sub-millisecond reads for the monitoring API without hitting Postgres on every poll
• Pluggable alert system — Log, email (SMTP), and webhook callbacks fire on RETRYING/DEAD transitions; extensible via register_alert_callback()
• REST API — GET /jobs/ (list + filter), GET /jobs/stats (aggregate counts), GET /jobs/<id> (detail), POST /jobs/retry/<id> (manual retry of DEAD jobs)
• PostgreSQL migration — job_executions table with proper indexes on job_id, status, and created_at

Frontend

• Job monitoring dashboard — Real-time status badges, stat summary cards, filterable table, manual retry buttons, 15-second auto-refresh
• TypeScript API client — Typed functions for all job endpoints

Tests (14 files, 1287 lines)

• Backoff math (exponential growth, cap, jitter, non-negative)
• Retry logic (success-first-try, retry-then-success, dead-after-max, traceback capture)
• Alert callbacks (log levels, webhook payloads, email gating)
• API endpoints (auth, listing, filtering, stats, detail, retry validation)

Tech

Flask + SQLAlchemy + Redis + APScheduler (all already in requirements.txt)

Closes #130

[zacharylyonstx]

Hey @rohitdash08 — just checking in. Job Retry feature is ready for review with full backend + frontend + tests. Let me know if you'd like any changes! 🙏