Feature/auth change password

[tidianecs]

What

Implements the /auth/change-password endpoint, one of the five
endpoints originally requested in #32.

Why

Per discussion on #32 with @DenizAltunkapan, I'm splitting this
issue into smaller, focused PRs instead of one large PR covering
all five endpoints. This PR covers change-password only; happy
to pick up the remaining endpoints in follow-up PRs.

Changes

• ChangePasswordRequest DTO (oldPassword, newPassword), with
  the same password strength validation used in registration
• AuthService#changePassword: identifies the current user from
  the JWT via the security context, verifies oldPassword against
  the stored hash, then hashes and persists newPassword
• POST /auth/change-password (protected endpoint, requires a
  valid access token)
• Integration tests covering:
  • successful password change
  • missing/invalid token → 401
  • wrong current password → 401
  • weak new password → 400
  • persistence: old password rejected and new password accepted
    on a subsequent login

How to test

1. POST /auth/register then POST /auth/login to obtain an
   access token
2. POST /auth/change-password with Authorization: Bearer <token>
   and { "oldPassword": "...", "newPassword": "..." }
3. Confirm login succeeds with the new password and fails with
   the old one

Notes

This is my first contribution to this project — feedback very
welcome, happy to make changes.

[DenizAltunkapan]

Thanks for the focused PR. The actual change-password implementation looks reasonable: it resolves the authenticated user from the security context, verifies the old password with BCrypt, stores the new hash, and includes useful integration coverage.

I would not merge this version yet because the PR also changes unrelated project/build/runtime configuration. Please address the inline comments first. After that, this should be close to approval.

Non-blocking follow-up: after a password change, we may also want to invalidate existing refresh tokens for that user so old sessions cannot keep refreshing indefinitely. That can be handled here or in a separate security-hardening PR.

[tidianecs]

@DenizAltunkapan I've addressed both points ready for another look, thanks.
About the Non-blocking follow-up, i'd suggest handling that in a separate follow-up PR to keep this one focused, happy to pick it up after this merges

[DenizAltunkapan]

@tidianecs thank you for your contribution