feat(auth): let an unverified account get a new OTP

[MOHITKOURAV01]

Summary

The verification code expires after 10 minutes and nothing anywhere issued a
second one. Registering again answered "User already exists", logging in
answered "Email is not verified", and there was no resend route — so a missed
code burned the address until a maintainer deleted the row by hand.

The UI made it easy to land there. Register.jsx held the verify step in
useState, so a refresh — or reading the code in another tab and coming back —
threw away both showOtpInput and data.email. The code sat in the inbox with
nothing left that knew which address it belonged to.

Related Issue

Closes #73

What changed

Backend

• POST /api/user/resend-otp, with a one-minute-per-address cooldown derived
  from a new otpLastSentAt field on the user rather than from anything the
  client sends. An unknown address, an already-verified account and a
  successful send all return an identical body — a resend route takes an
  address from an anonymous caller, and one that says "no such account" is an
  enumeration oracle.
• registerController stops collapsing two different cases. A verified
  account still answers "User already exists". An unverified row is a
  registration nobody completed, so nobody owns the address yet: the details
  are taken from the new attempt (the user may be retrying because they
  mistyped something) and a fresh code goes out.
• utils/otpCodes.js holds the length, lifetime, cooldown and mail copy in one
  place so registration and resend cannot drift apart. generateOtp moves off
  Math.floor(100000 + Math.random() * 900000) — Math.random is not a CSPRNG
  and this value is the only thing guarding the account. Same range, so the
  code is still exactly six digits.
• verifyOtpController clears otpLastSentAt, trims the submitted code, and
  returns canResend so the UI knows whether offering the button will do
  anything or only answer 429.

Frontend

• VerifyEmailPanel is shared by Register and Login and keeps the pending
  address in sessionStorage, which is what makes a refresh survivable. The
  value is an address the user just typed into a form on the same page.
• Login handles notVerified: true — the API has always sent it and nothing
  read it — and offers the verify step instead of a dead end.
• Register swaps its four alert() calls for the Toast Replace native browser alerts with a Toast/notification component in Login #36 introduced,
  disables submit while in flight, checks the 6-character password rule before
  sending, and stops labelling its password field current-password.
• The resend button counts down and seeds that countdown from the server's
  retryAfterSeconds rather than guessing.

Type

• Bug fix
• New feature
• Refactor
• Docs only
• Tests
• Config / workflow
• Security
• Breaking change

Areas touched

• Frontend
• Backend
• Database
• Docs
• Workflow / GitHub Actions
• Config / environment

Testing

• Tested locally
• Build passes
• Lint passes
• Tests added or updated
• Docs only, no runtime testing needed

npm test in backend/: 143 passing (128 before, 15 added). npm run build
in frontend/ passes.

Test steps

1. Register, never enter the code.
2. POST /api/user/resend-otp with that address → 200 and a new code.
3. Immediately again → 429 with retryAfterSeconds.
4. Same call for an address nobody registered → byte-identical 200, and no mail
   is sent.
5. In the UI: register, press F5 on the verify screen. The step is still there
   with the address intact.
6. Try to log in with an unverified account → the verify panel appears instead
   of just an error message.

Screenshots

• Not needed
• Added below

Edge cases checked

• Empty or missing data
• Loading / slow response
• API failure / server error
• Rate limit / throttling
• Invalid or unexpected input
• Permission / access denied
• Partial or inconsistent data
• Mobile / small screen behavior
• Other

Other edge case details

secondsUntilResend treats a timestamp in the future — clock skew between app
servers — as one cooldown rather than a lockout until that time passes. A
missing address is a 400 before any lookup happens. A database failure is a 500
that does not put the driver's message in the response body. sessionStorage
being refused (private browsing) degrades to the previous in-memory behaviour
rather than throwing.

Checklist

• Read CONTRIBUTING.md
• Linked the issue
• Assigned before starting or approved by maintainer
• Changes are focused on one issue
• No debug logs or unused code
• Documentation updated if needed
• No new warnings or console errors
• Changes are meaningful, not trivial

Notes

This is the missing recovery path, not throttling — #63 covers rate limiting on
the auth endpoints generally. The cooldown here exists because a resend route
without one is a free mail relay pointed at any address an attacker picks, and
it belongs on the route regardless of what #63 lands.

The re-registration behaviour is the part worth a second opinion: taking the
name/password/type from the new attempt is deliberate, on the grounds that
nobody has proven ownership of that address yet, so there is nothing to
protect. Happy to make it keep the original details if you would rather.

docs/issue-73-otp-resend.md has the full reasoning.

[MOHITKOURAV01]

Heads up on merge order: this branch and #77 both rewrite registerController, so they conflicted on backend/controllers/userControllers.js. Rather than leave that for whoever merges second, I rebased this branch on top of #77 and resolved it here.

The resolution keeps both fixes rather than picking one:

• the existence check uses fix(auth): make one email mean one account #77's normalised buildEmailFilter(value.email) and selects +otp +otpExpiry +otpLastSentAt, because an unverified row is re-issued a code below rather than turned away;
• fix(auth): make one email mean one account #77's E11000 guard moves from newUser.save() onto issueVerificationOtp(), since that helper is what writes the document now. It saves before it mails, so a rejected insert still sends nothing.

So this PR currently shows #77's commits in its diff. Merge #77 first and this one collapses to just its own changes. If you would rather they stayed independent, say so and I will unstack it — it will just mean resolving the same conflict at merge time.

Verified: npm test in backend/ is 158 passing on this branch, and merging #77 → #78 → #79 → #80 → #81 in sequence is clean with 190 backend tests passing on the combined result.

[MOHITKOURAV01]

Overlap with #100, worth deciding before either lands

Both merge cleanly into main as they stand, but they conflict with each other on backend/controllers/userControllers.js and backend/schemas/userModel.js, and the overlap is substantive rather than textual:

• this PR adds a resend endpoint that issues a new OTP for an unverified account.
• fix(auth): hash one-time codes and stop confirming which emails exist #100 makes every OTP a bcrypt hash with an expiry, an attempt counter and a single-use rule.

Whichever lands second has to take on the other's shape. Concretely:

• If fix(auth): hash one-time codes and stop confirming which emails exist #100 lands first, this PR's resend path must call issueCredential() and store credential.hash, and it should reset otpAttempts to 0 the way forgot-password does — otherwise an account that hit the attempt limit can never recover, which is the exact dead end this PR exists to fix.
• If this PR lands first, fix(auth): hash one-time codes and stop confirming which emails exist #100 must additionally convert the resend path, or it leaves one endpoint still writing a plaintext code and the guarantee is only partial.

I am happy to rebase whichever one you prefer to take second — just say which order you want and I will push the resolution.

My suggestion is #100 first, then this one: adapting this resend handler to issueCredential() is a few lines, whereas adapting #100 to an endpoint that does not exist yet is not reviewable.

[udaycodespace]

@MOHITKOURAV01 Everything looks good from my side. Merge conflicts are resolved, and the changes are aligned with the intended OTP resend flow. The updated auth handling and edge cases look good as well.

Approved to merge.