fix(frontend): prevent user message bubble overflow with long unbreakable strings - #3488

All committers have signed the CLA.

@SnapLap thanks for your contribution. Please fix the lint error and here are some review comments on the PR.

1. overflow-x-clip replaces overflow-visible globally — In message.tsx:48, the change from overflow-visible to overflow-x-clip affects all message types (user and assistant), not just user messages. If assistant messages had any intentional overflow behavior (e.g., tooltips or absolutely positioned elements), this could cause them to clip unexpectedly.

Suggestion: Consider scoping the overflow change to user messages only:
"overflow-visible group-[.is-user]:overflow-x-clip"

2. break-words on the wrapper vs. the content — The break-words class is added to the outer wrapper MessageContent, but the actual text is inside MessageResponse. Depending on the nesting, break-words on the parent may not propagate correctly to the deepest text node if there are intermediate elements with white-space: nowrap or similar. Worth verifying that the word-breaking actually applies where the text renders.

3. w-full max-w-full on bubble vs. assistant messages — In message-list-item.tsx:319, the change to AIElementMessageContent className="w-full max-w-full" affects the bubble for both user and assistant messages (this component is used for both paths in the same file). The original w-fit gave assistant messages a natural-width bubble. Now both will stretch to w-full, which may visually change how assistant responses look (they'll take full width even for short replies).

Suggestion: Apply w-full max-w-full conditionally:
<AIElementMessageContent className={cn(isHuman ? "w-full max-w-full" : "w-fit")}>

@WillemJiang Thanks for the detailed review! All three points addressed in this update:

1.overflow-x-clip scoping — You're right that it shouldn't be global. In fact, after deeper analysis, I realized message.tsx doesn't need any changes at all. My initial fix was over-scoped — I added overflow-x-clip there trying to clip overflow at the MessageContent level, but the real root cause is that the user message bubble in message-list-item.tsx lacked width constraints. Once max-w-full and min-w-0 are added to the wrapper div there, the original overflow-visible works fine for both message types. So message.tsx has been reverted to match main with no modifications.

2.break-words moved to inner element — Great suggestion. Moved from the outer MessageContent wrapper to AIElementMessageResponse, which directly wraps the rendered text. This ensures overflow-wrap: break-word applies at the text rendering layer with no risk of intermediate CSS interference.

3.w-full max-w-full conditional — Appreciate the suggestion! I initially implemented the ternary as you suggested, but upon closer inspection, this AIElementMessageContent is already inside an if (isHuman) block (line 302), so isHuman is always true here and the "w-fit" branch is unreachable. The assistant path uses a separate AIElementMessageContent (line 333) with its own className, so it's unaffected regardless. Simplified to just className="w-full max-w-full" to avoid dead code.