feat: Offline Progress Sync API (#51)

[nonsobethel0-dev]

Fixes #51

What changed

• Added SyncEvent Prisma model tracking idempotencyKey, deviceId, clientTimestamp, serverTimestamp, syncVersion, status, and rejectionReason
• POST /api/v1/sync/progress — accepts batched offline progress events; resolves conflicts by rejecting stale sync versions
• POST /api/v1/sync/completions — reconciles offline quiz/completion attempts; updates score when higher, skips when equal or lower, creates new completion when none exists
• Idempotency keys prevent duplicate processing of retried payloads
• Per-item results returned: applied, skipped, or rejected with a reason
• Both endpoints protected by JWT auth and rate-limited via authenticatedLimiter

Why

• Enables offline-first learning by accepting locally cached progress once the user reconnects
• Deterministic conflict resolution ensures data integrity without requiring client-server coordination

How to test

• POST /api/v1/sync/progress with { "events": [{ "idempotencyKey": "...", "deviceId": "...", "moduleId": "...", "progressPercent": 60, "clientTimestamp": "...", "syncVersion": 1 }] } → should return applied
• Retry the same payload → second call should return skipped
• Send a payload with syncVersion lower than an already-stored event → should return skipped with stale version reason
• POST /api/v1/sync/completions with valid events → applied if module exists and score is new or higher
• Send completion for a module already completed with higher score → should return skipped
• Send completion for non-existent module → should return rejected with reason

[drips-wave]

@nonsobethel0-dev 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