fix: reward history pagination/accuracy + course enrollment cache correctness

[Davidemulo]

Summary

• Reward #154 — getHistory returned every claimed reward with no pagination, unbounded for long-tenured users. Added page/limit (zod-coerced, matching the existing listCoursesSchema convention already used by /api/courses), a total count, and wired it through the route/controller with the same pagination response shape courses already return.
• Reward #153 — history hardcoded amount: REWARD_AMOUNT for every entry, so historical records would silently change if REWARD_AMOUNT is ever adjusted. Added quiz_submissions.reward_amount (migration 0006), persisted at the exact moment a claim is marked rewardClaimed: true (both processRewardClaim and RewardService.claimReward), and read back in getHistory. Pre-migration rows read null and fall back to REWARD_AMOUNT — an accurate backfill (that constant was the only value ever granted before this column existed), not a guess. Also switched history cache invalidation from a single key to cacheInvalidatePattern, since the cache key is now page/limit-scoped.
• Enrollment #151 — listCourses and getCourseDetail each independently re-queried the enrollments table for the current user on every authenticated request, regardless of whether the course list/detail cache itself was a hit. Added CourseService.getEnrolledCourseIds — caches a user's full enrolled-course-ID set (small, changes rarely) for 30s, used by both call sites instead of a live query each time.
• Course #152 — enroll()'s cache invalidation runs after the DB transaction commits — unavoidable, since Redis isn't part of the Postgres transaction and can't be made atomic with the commit. cacheDel/cacheInvalidatePattern already fail soft and every cache touched has a bounded TTL, so a transient failure was already recoverable, just undiagnosable as such. Centralized the four post-enroll invalidations (including the new enrollment-set cache) into one Promise.allSettled batch — reduces the commit-to-invalidation window from four sequential round-trips to one concurrent batch — and logs a single structured warning scoped to the specific enrollment if any sub-invalidation fails, rather than relying only on cacheDel's generic per-key warning.

Closes #151, Closes #152, Closes #153, Closes #154

Important caveat

Could not run the test suite — disk space on my machine was critically low (~1.7GB free) for this work, making npm install/running unsafe. Written by close reading of the existing course/reward service patterns and the courses module's established pagination convention. Please run tests/e2e/courses.test.ts and tests/e2e/rewards.test.ts before merging.

Test plan

• tests/e2e/rewards.test.ts passes, including new pagination coverage
• tests/e2e/courses.test.ts passes
• Manually claim a reward, confirm reward_amount is persisted and /api/rewards/history returns it (not a hardcoded constant) with correct page/limit/total
• Manually enroll in a course and confirm isEnrolled flips to true on the very next /api/courses and /api/courses/:id call (no stale cache read)

[drips-wave]

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