fix: correct password reset endpoint query logic

[NickMonrad]

Issue

Password reset was broken—users received 'Invalid or expired reset token' errors even with valid tokens.

Root Cause

1. Initial bug: The endpoint tried to use prisma.passwordResetToken.update({ where: { tokenHash, usedAt: null } }) which fails silently because Prisma cannot filter on null in composite unique clauses.
2. Race condition: After fixing the query, the usedAt === null check still happened outside the transaction. Two concurrent requests with the same token would both pass the guard, both enter the transaction, and both successfully reset the password (TOCTOU vulnerability).

Solution

• Move the usedAt: null guard inside the transaction using updateMany (which supports arbitrary WHERE clauses, not just unique constraints)
• Use updateMany to atomically mark token as used AND validate it hasn't been used yet
• Only proceed to password update if count > 0 (i.e., token was successfully marked used by this request)
• This ensures only the first concurrent request succeeds; duplicates are rejected before the password update

Changed Files

• server/src/routes/auth.ts (lines 129–166)

Fixes #233

Code Review

This PR passed code review by Sonnet 4.6, which identified and approved the race condition fix. The updateMany pattern is the correct way to handle conditional atomic writes in Prisma when using non-unique WHERE clauses.

Testing

• Schema validation tests pass (security.test.ts)
• Ready for manual E2E test with UI or Playwright