Fix for iOS text truncation issues on stroked text.

[andrewkunkel]

https://app.asana.com/1/236888843494340/project/1210546020714549/task/1216428483548702

Before (Android -> iOS)

After (Android -> iOS)

Tested this for all effects on iOS, and on multiple nameplate surfaces (You Bar, edit preview, member list).

In Claude's words:

Summary

Fixes iOS text truncation being dropped entirely when a text stroke is applied, on Fabric.

Our fork renders stroked text (RCTTextStrokeWidth / RCTTextStrokeColor) through a
two-pass Core Text path in RCTTextLayoutManager — pass 1 strokes the outline with
kCGTextStroke, pass 2 fills on top — instead of the usual
NSLayoutManager drawGlyphsForGlyphRange:. That path was handing CTFramesetterCreateFrame
the entire textStorage.

The problem

Core Text does its own line breaking and ignores the NSTextContainer's
maximumNumberOfLines and truncating lineBreakMode. TextKit had already measured and laid
out the text under the line limit, truncating the tail and drawing an ellipsis, and the draw
frame is sized to that clamped layout. Core Text, given the full string and a path rect of
frame.size, re-wrapped the overflowing trailing word onto a line that does not fit inside
that clamped rect — so it dropped the word completely, and Core Text draws no ellipsis of its
own.

The visible result: numberOfLines-limited text that should render as visible prefix… instead
lost its last word with no ellipsis, but only when a stroke was set. The non-stroke path was
always correct, because it just draws the glyphs NSLayoutManager already laid out and truncated.

The fix

Added getTruncatedAttributedStringForStroke(), which asks TextKit what it actually made
visible and rebuilds a string Core Text renders identically. Both Core Text passes now use that
string, and the stroke pass applies the stroke color over the rebuilt string's range rather than
the original character range (the rebuilt string has a different length).

[insacc]

nice!!