Set/update user's nickname use case

## Summary
Implement the backend feature allowing students to set or update their publicly visible nickname. Since users start without it (default `null`) but need one to post opinions, this is a core flow. This feature touches all layers of our backend architecture, from the API endpoint down to database constraints.

Before you begin implementation please describe here what business rules you propose for updating nickname, e.g.
- exact min/max characters length
- uniqueness (case sensitive or not)
- etc.

## [Acceptance criteria](https://www.atlassian.com/work-management/project-management/acceptance-criteria)
Criteria are split for each layer to make implementation easier:
- [ ] **Presentation:** REST endpoint is exposed for the authenticated user to update their own nickname.
- [ ] **Application:** A dedicated use case orchestrates the update, ensuring the user exists and validating uniqueness via the `Result` pattern before saving.
- [ ] **Domain:** The User entity encapsulates the nickname update logic, enforcing business rules (e.g. enforcing a min/max character length).
- [ ] **Infrastructure:** proper integrity contraints are applied to the nickname column via EF Core configuration to physically prevent duplicate entries (protection against race condition).
- [ ] **Infrastructure:** EF Core migration is generated

## Notes
Enforce uniqueness at the database level, but also check for uniqueness in the use case (via a repository read) to return a `Result.Failure` rather than relying on catching DbUpdateException for normal business flow.

Do not throw custom exceptions in the domain layer. Return `Result` objects for validation failures (e.g., nickname too short, invalid characters).