User's private profile page

## Summary
Implement the private user profile page. This is a place where a logged-in user can view all their account details and modify their mutable data (currently only nickname).

Since we also have a public profile page, you have the architectural freedom to decide how this is implemented: you can build a unified component that handles both views (public and private profiles) based on authentication state or keep them as two separate pages (e.g. public profile displays all public data while private profile only editable settings). You also have choice to design how private profile will be edited by users (e.g. inline editing, settings modal, global edit profile button, etc).

See issue of user's public profile for more details: #106

## Acceptance criteria
- [ ] The private profile is accessible via a secure route (with user friendly URL).
- [ ] The user can edit their nickname. The UI must handle validation, saving, and cancelling.
- [ ] The UI clearly indicates to the user which fields are publicly visible to other students and which are strictly private (or give a way to preview public profile of this user).
- [ ] In your pull request description, briefly explain your architectural choices (those from summary section in this issue).
- [ ] handle loading and error states with suspense and error boundaries.
- [ ] Implement mocked API calls (functions returning a stubbed user object) that can easily be swapped for a real API call later (use MSW). Contact with backend devs for API details
- [ ] Add a storybook stories showing this page and custom components in their view, loading, error states and edit state.

## Notes
- See figma designs for a reference about profile layout: ([1](https://www.figma.com/design/JANE25uq5sdrAuEM3viKVa/Untitled?node-id=19-2&t=F8jrTfz2ZpcUnPqg-0), [2](https://www.figma.com/design/0kVFdH1uo5CECYEVP1jHkg/AKAI-PROJECT?node-id=0-1&p=f&t=CbXxBzKKHDynCPzZ-0)). Utilize existing color palette, typography and avoid hardcoding tailwind styles (e.g. not using tailwind design tokens, but absolute units). Try to compose components starting from shadcn.
- Because this is a UI-centric page please add a storybook story for this page showing the loading, and error states and separate stories for custom components with logic that you made. Unit tests (vitest, react testing library) are recommended for ensuring that for example date formatting logic works correctly.

**I highly recommend implementing it in parts** and submitting separate pull requests to make code review easier.