feat(jobs): wire leaderboard snapshotting into a scheduled queue (#991)

[DSOTec]

Problem

createLeaderboardSnapshot(period, now) already exists in modules/leaderboard/leaderboard.service.ts — it rebuilds LeaderboardSnapshot rows for a period (WEEKLY / MONTHLY / ALL_TIME) and is already idempotent (delete + recreate inside one transaction). Nothing scheduled it though: no queue, no worker, no cron entry, so snapshots were never actually produced.

Solution

Wires it into the existing BullMQ job pattern used by analyticsDaily / creditRecompute / subscriptionCharge:

• src/jobs/leaderboardSnapshot.queue.ts — singleton queue via getQueue().
• src/jobs/leaderboardSnapshot.worker.ts:
  • runLeaderboardSnapshot() calls createLeaderboardSnapshot for all three periods, isolating failures per period ({ processed, failed }, same shape as processDueSubscriptions) so one bad period never blocks the others.
  • createLeaderboardSnapshotWorker() / scheduleLeaderboardSnapshot() register the BullMQ worker and a repeatable cron job.
• New LEADERBOARD_SNAPSHOT_CRON env var (default 15 0 * * *, daily) added to env.ts, .env.example, and config/index.ts.
• Wired into jobs/index.ts (exports) and jobs/main.ts (bootstrap + graceful shutdown), matching the other three jobs exactly.
• Updated main.test.ts's config mock and assertions for the 4th scheduled job / closable worker.

Idempotency: satisfied at the data layer — createLeaderboardSnapshot fully replaces a period's rows (delete + createMany) inside a single transaction, so re-running the job for the same period always converges to the same stored ranking regardless of how many times it fires.

Testing

• npx eslint on all touched files — clean (only the same no-explicit-any warning every other worker already has for redis as any).
• npm run typecheck — no new errors (this branch already has 4 pre-existing errors from an unrelated parsing issue in notifications.test.ts, untouched here).
• npx vitest run src/jobs — 23/23 pass (19 existing + 4 new), including a dedicated idempotency test (running the job twice in a row produces identical output).
• npm run test (full suite) — 508 passed vs. 504 on the unmodified branch (+4 mine), same pre-existing DB-dependent failures, no regressions.

Closes #991

[drips-wave]

@DSOTec 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