Implement RTL support

Here is Claude's analysis of what needs to be done:

RTL Support — Scope Assessment

A scoping write-up for adding right-to-left (RTL) language support to the interlinearizer
extension. This is exploratory — it estimates the work, it doesn't commit to a timeline.

TL;DR: Medium-sized effort, not a rewrite. The architecture is mostly RTL-favorable already
(coordinate-based arc geometry, scrollIntoView-based scrolling, some logical CSS in place). The
single biggest decision — and the thing most likely to expand scope — is whether text direction is
one global flag or threaded per writing-system (source can be RTL while glosses are LTR).
Settle that first; everything else follows.

---

Current state

• The app tracks a writingSystem (BCP 47 tag) on every token, plumbed through from the project
  setting into the tokenizer and onto each Token.
• It reads document.documentElement.dir === 'rtl' in exactly one place (to flip the
  prev/next navigation arrows)…
• …but it never writes dir anywhere. So in practice RTL text is currently laid out as LTR.

The team has clearly started thinking about RTL (logical CSS properties in the fade overlays, the
arrow flip, arc geometry that measures real pixel positions), but the foundation — actually
establishing direction — isn't wired up yet.

---

Work, by area

1. Establish direction — small code / design-heavy — DO FIRST

The keystone everything depends on. Today documentElement.dir is read but never set.

• Add an isRtlLanguageTag(tag) util that derives direction from the BCP 47 writingSystem
  (script-subtag lookup, or Intl.Locale().textInfo.direction where available).
• Apply dir to the DOM. Complication: source and target can have different directions
  (RTL Hebrew source, LTR English gloss). A single documentElement.dir is too coarse — this
  likely wants dir set per-strip / per-token based on each side's writing system, not one
  global flag.
• This design decision (global vs. per-side) is the real work and ripples into every area
  below.

2. Token strip ordering — medium — highest visual risk

Both views render the token strip as a plain flex row in document order. Flexbox will reverse
visually under an RTL ancestor — but only once dir="rtl" is actually set (see #1). After that:

• Verify SegmentView's multi-row wrapping lays out right-to-left, top-to-bottom correctly.
• Audit the doc-order ↔ visual-order assumptions in the code/comments. The sorting logic is fine
  (it sorts by document index, correct either way), but several comments literally say "visual
  left-to-right order" and need to be re-checked so nothing actually depends on doc-order ==
  left-to-right.

3. Arc geometry — small — mostly works already, needs verification

The arc path computation measures real getBoundingClientRect() values and normalizes spans with
Math.min/max, so arcs connect boxes wherever they land — this should survive RTL "for free."
Verify rather than rewrite:

• The gutter-side ("nearer left") choice is geometric, so fine — confirm the reserved left/right
  gutter padding lands on the correct visual side once boxes flip.
• Split-button positioning and de-confliction are pixel-based; should be fine but untested under RTL.

4. Physical → logical CSS — small, mechanical

A handful of physical left/right styles remain and should become logical (start/end):

• Token chip remove-badge -right-1.5 → -end-1.5.
• Baseline-text segment text-left → text-start.
• The view-options dropdown anchors with physical right + window.innerWidth - rect.right —
  needs RTL-aware positioning.
• A few modals use text-left / mr-1.
• Centered elements using left-1/2 -translate-x-1/2 are direction-neutral — no change needed.

5. Bidi correctness in mixed content — medium — easy to under-scope

The subtle one QA will catch late if ignored:

• Token chips carry no dir/lang despite each token having a writingSystem. RTL baseline with
  LTR glosses (or numerals/punctuation) will mis-order without per-element hints. Setting dir +
  lang per token from writingSystem is the clean fix.
• Gloss input fields need their own direction matching the analysis language, independent of the
  baseline.
• The verse-label + baseline concatenation in baseline-text mode needs bidi isolation so a numeric
  label doesn't reorder against RTL text.

---

Rough sizing

Area	Size	Risk
1. Establish direction (incl. global-vs-per-side decision)	S code / design-heavy	Foundational
2. Strip ordering	M	High visual risk
3. Arc geometry	S (verify + test)	Low
4. Physical → logical CSS	S	Low
5. Bidi / mixed-content correctness	M	Easy to under-scope

Overall: on the order of a week-ish of focused work plus QA with real Hebrew/Arabic data,
assuming the per-side direction question in #1 is settled early. Note the test suite enforces 100%
coverage, so every component touched needs RTL test cases added.

---

Recommended first step

Decide #1: global vs. per-side direction. That single call determines whether dir is one flag
or threaded per writing-system through tokens, glosses, and strips — and therefore the true size of
everything else.

Start by reviewing the existing document.documentElement.dir read, SegmentView strip ordering, token chips, gloss inputs, and baseline-text rendering. First resolve whether direction is global or per-side/per-token, then trace the affected RTL and bidi behavior across those areas. Done means RTL layouts, mixed-direction content, CSS positioning, arc geometry, and coverage tests work with Hebrew or Arabic data.