Adding Change Username Endpoint

[tidianecs]

Summary

Implements the /auth/change-username endpoint, one of the five
endpoints originally requested in #32. Follows the same pattern
established in the /auth/change-password PR: the current user is
resolved from the security context (not a client-supplied
identifier), the new username is validated for uniqueness before
being persisted, and a no-op request (new username identical to the
current one) is rejected explicitly.

Linked issue

Closes #32 (partially — covers change-username only, as agreed
with @DenizAltunkapan; other endpoints to follow in separate PRs)

How to test

1. POST /auth/register then POST /auth/login to obtain an access token
2. POST /auth/change-username with Authorization: Bearer <token>
   and { "newUsername": "..." }
3. Verify:
   • missing/invalid token → 401
   • new username identical to current one → 400 ("You didn't change anything")
   • new username already taken by another user → 400 ("User with
     username ... already exists")
   • empty username → 400
   • successful change → 200, and a subsequent login with the old
     username fails while the new username succeeds

Notes / Risk

No migrations or flags involved. Low risk: change is scoped to a
single new endpoint and its service method, no existing behavior
touched. Same non-blocking follow-up as the change-password PR
applies here too — refresh tokens aren't invalidated after a
username change; can be handled in a dedicated security-hardening
PR if desired.

[DenizAltunkapan]

@tidianecs thanks!