feat: Add fallbackClassName prop to AvatarGroupItem

[robdimarco-atxp]

Problem

AvatarGroupItem was passing the same className to both the Avatar container and AvatarFallback, causing class conflicts:

• Background colors intended for the fallback (e.g., bg-indigo-500) were also being applied to the container
• Border classes intended for the container (e.g., border-2 border-surface-primary) were also being applied to the fallback
• This made it unclear which element would get which styles
• Even with tailwind-merge, the mixing of concerns was confusing

Solution

Add a separate fallbackClassName prop specifically for AvatarFallback styling:

• className → Avatar container (border, sizing, positioning)
• fallbackClassName → AvatarFallback (background, text color)

The default bg-muted text-foreground remains in AvatarFallback, so it won't be blank when no fallbackClassName is provided.

Benefits

1. Clear separation of concerns - Container styling vs fallback styling are explicit
2. No class conflicts - Each element gets only its relevant classes
3. Better API - Usage intent is clear and documented
4. Backward compatible - Existing usage with className still works

Example Usage

// Before (ambiguous - same classes on both elements)
<AvatarGroupItem 
  fallback="JD"
  className="bg-indigo-500 text-white border-2 border-surface-primary"
/>

// After (explicit - clear separation)
<AvatarGroupItem 
  fallback="JD"
  className="border-2 border-surface-primary"
  fallbackClassName="bg-indigo-500 text-white"
/>

Breaking Change

No - This is additive. Existing usage with className still works, but components that were relying on className to style the fallback should migrate to fallbackClassName for clarity.

Test Plan

• ✅ Built package successfully
• ✅ Updated LibreChat to use fallbackClassName
• Verify avatar colors now render correctly with no conflicts
• Check other components in design system using AvatarGroupItem