fix(rioterm): render RTL runs (Arabic/Farsi/Hebrew) correctly

[saeidakbari]

Summary

RTL text (Arabic, Farsi, Hebrew) rendered with every glyph crammed into one column. After a naive per-cell reversal, narrow glyphs (alef) still showed gaps inside words like آیا.

Root cause

build_row_fg's cluster→cell walk was forward-only:

while cell_starts[cell_idx + 1] <= g.cluster { cell_idx += 1 }

Shapers (CoreText, HarfBuzz/swash) return RTL runs in visual order with monotonically decreasing clusters — glyph 0 is the logically-last character. So the cursor jumped to the run's last cell on glyph 0 and stayed pinned: every glyph was emitted at the same grid_pos.

Additionally, snapping proportional Arabic glyphs to monospace cell origins leaves whitespace before narrow glyphs.

Fix

attribute_glyphs_to_cells() detects RTL via first.cluster > last.cluster (the documented shaper convention) and lays RTL runs out pen-relative:

• a pen advances by each glyph's real shaped advance from the run's left edge
• the glyph's cell is floor(pen / cell_w)
• the sub-cell remainder goes into bearings[0] (renderers already add i16 pixel bearings to the cell origin — no renderer changes needed)

Tight packing eliminates the gaps. Fg colour still follows the cluster's logical cell so selection/cursor semantics are unchanged. LTR runs take an identical code path as before (extra_x = 0).

Testing

• synthetic LTR / RTL / combining-mark attribution tests
• end-to-end CoreText test shaping real Farsi (سلام) through the production shape_text_utf16 path, asserting each glyph reconstructs its pen position
• full rioterm suite: 211/211 pass

Known limitation

Pure-RTL runs only. Mixed Latin-inside-RTL lines need full UAX#9 bidi reordering.