Add right-to-left (RTL) text support

[kfatehi]

Adds right-to-left (RTL) text support for Farsi, Arabic, and Hebrew. Closes #174.

What it does

• Rendering: message bubbles, reply bubbles/previews, conversation-list titles/subtitles, and the send-animation bubble render with the correct paragraph direction (RTL text aligns right; trailing punctuation/emoji land correctly). Reaction/reply/notification text embedding an RTL message is wrapped in a Unicode first-strong isolate so it orders correctly in the surrounding sentence.
• Input: the compose and subject fields go RTL (right-aligned, RTL base direction) as you type RTL text, via TextDirectionBuilder — which recomputes direction live but rebuilds the field only when the first-strong direction actually flips, not on every keystroke/selection change, so caret dragging works normally.
• Emoji-corruption fix: prevents the ?? surrogate-pair corruption that RTL input could trigger (see "Emoji corruption" below).

How

• getTextDirection() (lib/helpers/ui/text_direction_helpers.dart): UAX#9 "first strong character" detection over runes — chosen over intl's Bidi.startsWithRtl, which misclassifies emoji-leading text as LTR (the leading surrogate falls in its LTR ranges).
• Rendering: applied as the textDirection of each message RichText/Text.rich and the conversation tile; getNotificationText wraps embedded text in a first-strong isolate (U+2068…U+2069).
• Input: each compose TextField is wrapped in TextDirectionBuilder (direction-flip-gated rebuild).
• Caret clamp: SpellCheckTextEditingController.set value snaps a collapsed caret (or selection endpoint) off any UTF-16 surrogate-pair interior — snapSelectionOffSurrogatePairs() in lib/helpers/ui/grapheme_caret.dart — before committing the value, so a subsequent edit can never split an emoji. The caret snaps to after the cluster (the trailing edge), so when a tap lands inside a trailing emoji's glyph the caret ends up past it and a backspace deletes the emoji — in RTL, snapping to the leading edge would instead strand the caret before the emoji and delete the adjacent space.

Emoji corruption — fixed (this was the draft blocker)

Earlier this PR carried an intermittent ?? corruption while composing. With an RTL base direction, tapping on an emoji glyph can land the caret inside the emoji's UTF-16 surrogate pair; the next keystroke then splits the pair into two lone surrogates, which the Android text-input channel encodes as ? (giving ??) and which also crash ParagraphBuilder on paint.

This is a pre-existing Flutter framework bug, not something this PR's RTL approach does wrong: Flutter allows a caret to sit inside a surrogate pair and forwards that offset to the platform IME. RTL input is only the trigger — an LTR tap happens to snap the caret to the grapheme boundary, whereas an RTL tap can land it mid-pair; the standalone repro reproduces the defect with plain Latin text and no RTL at all. It's filed with a deterministic, device-free repro and fixed upstream:

• Issue: Caret can be placed inside an emoji's UTF-16 surrogate pair; editing there splits it -> text corruption + Paragraph build crash (selection not clamped to a grapheme boundary) flutter/flutter#188713
• Standalone repro: https://github.com/kfatehi/emoji-caret-repro (passes on Flutter 3.24.0 and latest stable)
• Framework fix PR: Do not report a caret inside a surrogate pair to the platform IME flutter/flutter#188719

This PR fixes it in-app, with no Flutter upgrade required: because EditableText forwards the controller's value to the IME, clamping the caret in our own compose controller is equivalent to the framework fix, and it's scoped to the compose field only. Verified on-device — Farsi + emoji + tap-on-the-emoji + typing no longer corrupts.

Tests

• test/rtl_detection_test.dart — getTextDirection over Farsi, emoji/punctuation/digit-leading Farsi (first-strong), English, empty/null, and mixed first-strong.
• test/grapheme_caret_test.dart — the caret clamp: a caret inside a surrogate pair snaps to the pair boundary, boundary carets are untouched, and inserting at the snapped caret leaves the emoji intact.

Note on mixed-direction text

Mixed LTR/RTL/emoji runs are laid out by Flutter's standard Unicode Bidi Algorithm — the same reordering iMessage and the platform keyboards apply for a given base direction. Intentional, not a rendering bug.

Mirrored in the BlueBubbles PR: BlueBubblesApp#3049 (kept source-only there, since that base has flutter_test disabled; the tests live here).

[kfatehi]

Drafted again due to discovery of some bugs, will be tracking in the BlueBubbles ticket BlueBubblesApp#3049 and then backport the fixes here once I have them

[kfatehi]

Update — un-drafted, ready for review again.

The ?? emoji corruption that made me re-draft is fixed: the compose controller now clamps the caret out of any UTF-16 surrogate-pair interior, so an edit can't split an emoji into lone surrogates. Tracking it down also surfaced a related RTL annoyance — with a trailing emoji the caret landed on the wrong side, so backspace deleted the preceding space instead of the emoji; it now snaps past the emoji so backspace removes it. Both verified on-device (Farsi + Gboard).

The same fix is upstreamed at flutter/flutter#188719 (now approved by a Flutter maintainer). Because EditableText forwards the controller's value to the IME, the in-app clamp is equivalent and works on the current Flutter pin with no SDK bump — so this PR carries the corruption fix itself. Full details in the updated description.