fix: send real password reset link instead of dummy route

[Kanavpreet-Singh]

Problem

Password reset emails contained the literal string dummyFrontEndRoute?token=<uuid>
instead of a usable link, so no user could ever complete a reset.

verify.base.frontend was already defined in application.yml but was read by
nothing — the only @Value in the whole codebase was jwt.secret.

Changes

• EmailService now builds the real link from verify.base.frontend plus a new
  verify.reset.path property, pointing at the existing frontend route
  /forgot-password/change-password?token= (see pages/forgot-password/change-password.tsx
  in the website repo, which already reads token from the query string).
• Added the missing setFrom. Gmail silently substitutes the authenticated
  account, which is why nobody noticed; any other SMTP server rejects the message
  with 553 5.1.3 The address is not a valid RFC 5321 address. This matters if we
  ever move off Gmail.
• Reworded the email body and stated the 15-minute expiry, which matches the
  existing check in UserService.changePassword.
• .gitignore: added secret.json / serviceAccount*.json so credential files
  can't be committed by accident.

Config

New property, defaulted in code so existing environments keep working:

verify:
  reset:
    path: forgot-password/change-password

Testing

• Ran the built jar against the real acmcss@pec.edu.in SMTP account; the email
  was delivered and contained
  https://pecacm.in/forgot-password/change-password?token=<uuid>.
• That URL returns 200 (redirects to www.pecacm.in, token preserved).
• Full flow verified locally against a Dockerised Postgres: token issued,
  single-use, 15-minute expiry, cross-user token rejected 401, unknown email 404,
  blank password 400, password actually changes and the old one stops working.

Not in this PR

• The frontend repository/auth.ts still stubs sendResetEmail and
  changePassword — they return "This feature is still under testing" and never
  call the backend. The feature is not user-complete until that is implemented.
• POST /v1/user/forgot-password still requires a username query param, but the
  frontend reset page only has the token and the new password. Worth deciding
  separately whether the backend should derive the user from the token.