fix(gamification): normalize attendanceDate so awardXp accepts string or Date

[hariom888]

Context

#3806 reported a duplicate-XP-award race between a synchronous awardXp() call and a queued AWARD_GAMIFICATION_XP job in app/api/attendance/sync/route.js. That code path doesn't exist in the current repo — the route only calls enqueue(), and awardXp already enforces idempotency per (firebaseUid, "attendance_marked", date) via an attendanceHistory check, a uniquely-indexed xp_awards collection, and a distributed lock (withLock).

While writing the idempotency regression test #3806 asked for, against realistic offline-sync inputs, I found a different, real bug living in that same idempotency code.

Problem

app/api/attendance/sync/route.js passes metadata.attendanceDate as a "YYYY-MM-DD" string (from getLocalDateKey()). But lib/gamification-service.js assumed it was always a Date instance:

• processStreak(student, attendanceInstant) → daysBetween() calls attendanceInstant.getFullYear() directly.
• updateFields.lastAttendanceDate = (metadata.attendanceDate || now).toISOString() calls .toISOString() directly.

Both throw TypeError: ... is not a function on a plain string. This was masked on a student's first attendance award, since processStreak short-circuits when there's no prior lastAttendanceDate — but every subsequent offline-synced award threw, got caught by the queue worker's error handling, retried 3 times (all failing identically), and ended up in the failed-job queue. Net effect: offline-synced attendance was awarding zero XP after a student's first record — the opposite of double-awarding.

The online path is unaffected since it doesn't pass attendanceDate at all.

Fix

Normalize metadata.attendanceDate once, right where it's first used, into:

• effectiveDate — a plain string, used for the idempotency lookups (attendanceHistory comparison, xp_awards.date) and persisted date fields, which were always plain strings elsewhere anyway.
• attendanceInstant — a real Date instance, used for processStreak()/daysBetween() and the .toISOString() call.

Both a string and a Date instance are accepted; if neither is provided, both fall back to now/today's date string exactly as before.

Tests

lib/__tests__/gamificationXpIdempotency.test.js (5 tests):

• Sequential duplicate calls → one award, one no-op, xp_awards written once.
• Concurrent duplicate calls (serialized via a withLock mock that faithfully reproduces the real Redis-backed mutex) → one award, one no-op.
• Different dates are not treated as duplicates.
• Regression test for this fix: a string attendanceDate on a student's second (consecutive-day) award no longer throws, and the streak correctly continues.
• A Date instance is still accepted, for backward compatibility.

The pre-existing lib/__tests__/gamification-service.test.js (which exercises attendanceDate as a Date) still passes unchanged.

Closes #3806