fix(auth): rate-limit OTP verification to block brute force (#70)

[Rudra-clrscr]

Closes #70

Problem

The password-reset OTP verification endpoint (app/api/auth/verify-otp/route.ts)
had no attempt limit, lockout, or delay. Although codes are 6 digits with a
10-minute expiry, an attacker could repeatedly guess against the ~900,000
possible codes within the validity window and take over an account.

Fix

Track failed guesses per issued code and invalidate the code once the budget
is spent (the approach proposed in the issue):

• failed_attempts column on password_reset_otps
  • supabase/migration-otp-failed-attempts.sql — idempotent ADD COLUMN IF NOT EXISTS for existing deployments
  • supabase/migration-otp-table.sql — column added to the CREATE TABLE so fresh installs get it too
• verify-otp logic
  • increments the counter on every wrong guess and surfaces the remaining attempts in the error message
  • after 5 incorrect guesses, deletes the code and responds 429, forcing a fresh reset request
  • correct codes within the limit verify normally (unchanged happy path)

Because forgot-password deletes and re-inserts a fresh OTP (counter back to 0),
requesting a new code restores the attempt budget.

Acceptance criteria

• Table tracks failed attempts per OTP
• N (5) incorrect guesses trigger OTP invalidation
• Valid codes within the limit continue functioning normally

Deployment note

The migration must be applied to the Supabase database before/with deploy,
otherwise the failed_attempts read/update will error.

Known limitation

The counter is a read-modify-write and is not atomic, so tightly concurrent
requests could slip a few extra guesses past the threshold. The count is still
bounded to a tiny number — nowhere near brute-force range. Happy to follow up
with an atomic Postgres RPC increment if preferred.

Testing

• tsc --noEmit: clean on the changed route (no new type errors).
• Not run live: no local .env/Supabase, and it requires the migration applied
  to the DB. Suggested manual check once deployed — request a code, submit 5
  wrong guesses, confirm the 5th returns 429 and the code no longer works.

[vercel]

@Rudra-clrscr is attempting to deploy a commit to the vishwamistrylearning-1037's projects Team on Vercel.

A member of the Team first needs to authorize it.