Composer and message bubbles don't respect right-to-left text direction

Start in src/features/chat/ui/ChatInput.tsx at line 1915 and trace the shared rendering paths through LinkifiedText, MessageBubble.tsx, and src/shared/ui/ai-elements/message.tsx. Check both ChatInput consumers, including HomeComposer, and verify that Arabic content follows its direction while English remains unchanged. Done means the composer and both message types use content-based direction without changing the surrounding interface layout.

Before filing (3 checkboxes — all must be ticked)

• I searched open and closed issues for duplicates.
• I am using a recent release and this doesn't already exist.
• This is one request, not several bundled together.

Closest existing issue

none found

Is this new, or an improvement?

New capability — Berd can't do this at all today

The problem, in your terms

I write to Berd in Arabic. Arabic is a right-to-left script, and every place Berd
renders my text treats it as left-to-right.

In the composer, an Arabic sentence starts at the left edge of the box and runs
away from where my eye expects it. Punctuation lands on the wrong side — a
question mark typed at the end of an Arabic sentence renders at the far left,
which reads as though it belongs to the previous line. Editing is worse than
writing: placing the cursor mid-sentence to fix a word means aiming at a caret
whose position doesn't match the visual order of what I typed.

The same happens after I send. My message renders left-aligned in its bubble,
and so does the model's Arabic reply. A conversation held entirely in Arabic is
displayed with the alignment and punctuation placement of a language it isn't in.

This is not about the interface being in English. English menus and settings are
fine and I'm not asking for those to change. It's that Arabic content — mine
and the model's — is rendered left-to-right.

What you do today

Nothing that works. For short messages I accept the bad alignment. For anything
long I switch to English, which defeats the point of the app supporting my
language at all.

What you'd like to see

Apply dir="auto" at the points where user-authored and model-authored text is
rendered, so the browser resolves direction per content from the first strong
directional character. Arabic content renders right-to-left; English content is
unaffected.

From reading the source at v0.6.2, the relevant places look like:

1. The composer textarea — src/features/chat/ui/ChatInput.tsx:1915. This
   one element covers both composers, since src/features/home/ui/HomeComposer.tsx
   renders ChatInput.

   <textarea
     ref={textareaRef}
     dir="auto"
     value={text}
   

2. User message text — LinkifiedText (src/shared/ui/LinkifiedText.tsx),
   rendered from src/features/chat/ui/MessageBubble.tsx:534.

3. Model message text — MessageResponse
   (src/shared/ui/ai-elements/message.tsx), rendered from
   src/features/chat/ui/MessageBubble.tsx:569.

I may well have missed render paths — that's your call, not mine. The principle
is what I'm asking for: content direction should follow the content.

One honest limitation. On a <textarea>, dir="auto" resolves a single
direction for the whole field from its first strong character, not per
paragraph. So a message that opens in English and later contains an Arabic
paragraph would still render that paragraph left-to-right. That's a real gap,
but it's a much smaller one than today's, and I'd rather have the common case
right than wait for the complete solution. In the message bubbles, where content
is already split into blocks, per-block dir="auto" gets closer to correct.

Why this belongs in Berd itself

It can't be done from outside. A skill, an agent, an extension and an automation
all operate on the content of a conversation — none of them can change how
Berd's own React components render it. Text direction is decided by the app's
markup, so the app is the only place the fix can live.

It's also not something a user can work around locally. There's no setting, no
stylesheet hook, and no per-conversation option that affects it.

For what it's worth, the codebase looks ready for this. Berd already ships real
i18n infrastructure (src/shared/i18n/, 16 namespaces, en and es), so
localization is clearly a considered concern rather than an afterthought.
Direction just hasn't come up yet, presumably because both shipped locales are
left-to-right. As of v0.6.2 there is no dir attribute anywhere in src/, and
index.html hardcodes <html lang="en"> with no dir.

Non-goals

I am not asking for:

• An Arabic translation of the interface. No ar locale, no new translation
  namespaces, no strings to maintain. The interface staying in English is fine
  and I'd prefer it.
• Right-to-left layout for the app. No dir="rtl" on the document, no
  mirrored sidebar, navigation, icons or panels, no audit converting physical CSS
  properties to logical ones. That is a much larger and riskier change and it is
  not what this issue is about.
• A direction setting or toggle. dir="auto" needs no preference — it
  resolves from the content. Adding a switch would be more surface area for less
  correctness.
• Any change to how English renders. dir="auto" resolves to ltr for
  English content, so existing behaviour should be unchanged for everyone not
  writing in a right-to-left script.

The edge of this request: content direction only, in the composer and the
message bubbles. Chrome stays exactly as it is.

Alternatives you considered

• dir="rtl" on the document, driven by a locale. Rejected. It would require
  an Arabic translation I'm not asking for, it would mirror the entire layout,
  and it would still be wrong the moment I write an English message. Direction
  belongs to the content, not to the interface language.
• A user setting to force composer direction. Rejected. It's a manual
  workaround for something the browser already determines correctly on its own,
  and it breaks as soon as someone writes in both languages, which I do.
• CSS text-align: right. Rejected. It moves the text to the right without
  making it bidirectional, so punctuation and mixed-script runs stay wrong. It
  looks like a fix and isn't one.

Mockups, prior art, or other context

Prior art is the HTML standard itself: dir="auto" exists for exactly this case,
and is the recommended approach for user-generated content of unknown direction.
The WHATWG spec calls it out for "text input fields and textareas" and for
displaying user-submitted content.

Environment: Berd 0.6.2, Linux (Ubuntu, x86_64), installed from the
Berd_0.6.2_linux-x86_64.deb release.