feat(auth): Sync user profile pictures from SAML on login

[Asynchronite]

Summary

Adds optional syncing of a user's profile picture from their SAML identity
provider during SSO login. When an organization's SAML provider maps the new
avatar attribute to a SAML assertion attribute carrying base64 image data,
that image becomes the user's avatar on each login.

This is opt-in and provider-scoped: organizations whose SAML attribute
mapping does not include avatar are completely unaffected, and non-SAML SSO
providers (Google, GitHub, etc.) are never touched.

What changed

• SAML2Provider.build_identity now extracts an avatar attribute (when
  mapped) and attaches the validated image to the identity as
  identity["avatar"].
• _validate_saml_avatar validates the assertion value: base64-decodes it
  (accepting an optional data:<mimetype>;base64, prefix), and checks the
  format (PNG/JPEG/GIF) and size (SENTRY_MAX_AVATAR_SIZE). It does not
  enforce dimensions, since IdPs send varying sizes and stored avatars are
  resized on read. It never raises — a malformed picture is dropped so it
  can't block login.
• AuthIdentityHandler._apply_sso_avatar applies the picture on login,
  wired into all SAML login paths: handle_existing_identity (repeat logins),
  handle_attach_identity (linking), and handle_new_user (first-time). It is
  gated on provider.is_saml, and any failure is logged and swallowed so SSO
  login always completes.
• user_service.update_user_avatar (new RPC) stores the decoded image as an
  uploaded UserAvatar, or resets the user to the default letter avatar when
  given an empty value. The avatar lives in the control silo alongside the auth
  pipeline, so no cross-silo image transfer is needed.

The base64 image is used transiently to set the avatar and is not persisted
to the AuthIdentity row.

How to enable

Map the avatar attribute to the IdP attribute carrying the user's base64 photo
in the SAML provider's attribute mapping, e.g.:

{
    Attributes.IDENTIFIER: "id",
    Attributes.USER_EMAIL: "email",
    Attributes.FIRST_NAME: "first",
    Attributes.LAST_NAME: "last",
    Attributes.AVATAR: "photo",  # IdP attribute holding base64 image data
}

Testing

• _validate_saml_avatar: valid PNG, data: URI stripping, non-image, invalid base64, empty/missing.
• build_identity: avatar present when mapped + valid, omitted when invalid, omitted when unmapped.
• user_service.update_user_avatar: upload + reset-to-letter-avatar.
• Login application: applied for SAML, skipped for non-SAML providers, no-op when no avatar is present, and failures swallowed (login not broken).

Notes / follow-ups

• handle_existing_identity runs on every SAML login, so if the IdP sends the photo on each assertion the avatar is re-decoded and re-stored every login (new file blob, old one deleted). Correct but wasteful at scale; a follow-up could hash the incoming image and skip re-upload when unchanged.
• No UI is added to the generic SAML setup form for the avatar mapping; it is configured via the provider's attribute mapping. A setup-form field could be added later (frontend-only change).

Closing issues

Closes #104496.

Legal Boilerplate

Look, I get it. The entity doing business as "Sentry" was incorporated in the State of Delaware in 2015 as Functional Software, Inc. and is gonna need some rights from me in order to utilize my contributions in this here PR. So here's the deal: I retain all rights, title and interest in and to my contributions, and by keeping this boilerplate intact I confirm that Sentry can use, modify, copy, and redistribute my contributions, under Sentry's choice of terms.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

There are 2 total unresolved issues (including 1 from previous review).

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 4a34499. Configure here.}

[Asynchronite]

Should be good now