Description

Implements the Profile half of #553: a self-service account page for any
signed-in user. Today a regular user can only see their identity in the
Admin → User Management table, and only if they're an admin — this gives every
user one place to see who they're logged in as, pick an avatar, and sign out.

The Admin → User Management redesign (the other half of #553) will follow as a
separate, independent PR.

Frontend — a new /profile route (under the existing (utility) group):

• Account info: username, role badge, join date.
• Avatar: upload your own picture or pick from a predefined icon set
  (16 icons × 8 colors). Uploads are cropped to a square and resized to 256px
  client-side via <canvas> (which also strips EXIF), keeping the stored file
  small.
• Sign out.
• A shared UserAvatar component (image → picked icon → deterministic fallback
  by username hash). Admins get an amber ring + shield badge, always paired with
  an aria-label/role badge so the cue is never color-only.

Backend — no new dependencies:

• UserRecord gains an optional, backward-compatible avatar marker
  ("", "icon:<name>:<color>", or "img:<version>"); surfaced on
  /auth/status and /auth/users.
• New endpoints: GET/PUT /api/v1/auth/profile,
  PUT/DELETE /api/v1/auth/profile/avatar, GET /api/v1/auth/avatar/{user_id}.
• Uploaded images are validated by magic bytes (PNG/JPEG/WebP only; SVG
  rejected as a stored-XSS vector), capped at 1 MB, stored on disk under
  multi-user/_system/auth/avatars/<user_id>.<ext> with an atomic
  write-then-replace, and served with nosniff + private caching. Deleting a
  user also removes their avatar file.

Related Issues

• Related to [Feature Request]: User profile page (account + avatar) and a lighter Admin page #553

Module(s) Affected

• agents
• api
• config
• core
• knowledge
• logging
• services
• tools
• utils
• web (Frontend)
• docs (Documentation)
• scripts
• tests
• Other: multi_user (identity store / user model)

Checklist

• I have read and followed the contribution guidelines.
• My code follows the project's coding standards.
• I have run pre-commit run --all-files and fixed any issues.
• I have added relevant tests for my changes.
• I have updated the documentation (if necessary).
• My changes do not introduce any new security vulnerabilities.

Additional Notes

Rebased onto the latest dev and verified end-to-end in the Docker build (auth
enabled): login → Profile link in the sidebar → upload an image, pick an
icon/color, remove photo, and sign out all work. Screenshots below.

Design decisions (answering the open questions in #553):

• Route, not popover — fits the existing (utility) group.
• Hybrid avatars (upload and an icon set that also serves as the fallback);
  stored in the user record, with image bytes on disk rather than in the user
  JSON.
• Profile endpoints require auth but not admin; a user can only edit their
  own record, and img: markers can only be set via the validated upload
  endpoint.

Intentional tradeoffs (happy to change):

• /auth/status now reads the user store to include the avatar marker so the
  sidebar avatar needs no extra request — could be cached for very large user
  stores.
• set_avatar takes the existing users-file write lock; the sibling
  delete_user/set_role helpers predate it and don't — I left that asymmetry
  alone to keep the diff scoped, happy to align them.
• With AUTH_ENABLED=false (default localhost mode) the Profile link is hidden
  and the page redirects, matching the existing admin-area behavior.

This is a proposal, not a fixed design. If you disagree with any of it, or want
something added, reworked, split up differently, renamed, or dropped — no problem
at all, I'm happy to discuss and iterate on whatever direction you prefer.

Screenshots

Profile — uploaded image (admin)	Profile — picked icon (admin)	Profile — regular user

Sidebar — expanded	Sidebar — collapsed