feat(api): let a table cell say which way its text runs

[DemchaAV]

Why

2.2.0 gave a paragraph a writing direction. A table cell written as a plain string —
table.row("…"), DocumentTableCell.text(…) — never got one, because that path is
measured and drawn by the table's own layout rather than by the text pipeline. It
therefore received neither half of what makes Hebrew and Arabic correct: the same string
drew reversed in a cell while drawing properly in a paragraph, and Arabic came out in
isolated letters instead of joined. The Hebrew invoice example builds its line items from
rows rather than a table for exactly that reason, and said so in its Javadoc.

What changed

• DocumentTableStyle.direction(...) takes the same LTR / RTL / AUTO a paragraph
  does and inherits down the cascade a cell style already follows — table default, column,
  row, cell — so one call turns a whole table round.
• The cell is the unit AUTO reads.TableLayoutSupport.answerDirection resolves it
  against that cell's own lines, so two cells under one declared direction answer it
  separately, and a cell's second line does not run the other way from its first because it
  opens on Latin. The fixed-layout backends consume that answer from the resolved
  TableCellLayoutStyle rather than re-deriving it; the semantic DOCX backend does not see
  a LayoutGraph at all, so it resolves the same public cascade through the same
  ParagraphDirection — one rule, reached two ways, rather than two rules.
• Direction decides the edge only when no anchor was asked for — the rule a paragraph
  already follows for alignment. The author's style cascade is now merged on its own before
  the built-in defaults go underneath it, because TableCellLayoutStyle.DEFAULT fills the
  anchor for every cell and would answer "somebody set it" every time. The fold is
  property-wise last-non-null-wins, so the two orders are equivalent; every existing layout
  snapshot and pixel baseline is unchanged.
• Auto columns are measured on the joined forms (cellNaturalWidth shapes before
  measuring). An unjoined Arabic string is wider than the one the page draws, so the column
  was being sized to text that never appears. Reordering moves no glyph and changes no
  advance, so it has nothing to say to measurement.
• PDF shapes and reorders the line at the drawing seam and wraps a reordered line in an
  ActualText marked-content section, so a reader copies out the letters that were typed.
• PowerPoint is told the direction on the cell's frame and receives the text as written,
  mirroring nothing. This is the opposite of what the paragraph handler does, for a reason:
  a paragraph arrives as one frame per span, so no frame holds a bracket pair for PowerPoint
  to resolve and the swap has to be made first; a cell is one frame holding a whole line,
  which is the input PowerPoint's own algorithm is complete for. Pre-mirroring that line
  swaps the brackets a second time — (2026) closing an Arabic cell drew as )2026(.
• Word needed a second property, and so did every paragraph before this.w:bidi
  settles which edge a line starts from and nothing else; how Word resolves the characters
  inside a run comes from w:rtl, and a run without it is handled as Latin, with paired
  punctuation left unmirrored. Every right-to-left run now carries it, in a paragraph as
  well as a cell. The paragraph path has had this gap since direction shipped: it is
  invisible in Hebrew and needs Arabic, where digits following a letter resolve as an Arabic
  number rather than a European one. Measured in Word one property at a time; w:cs and
  w:lang were tried and are not required.
• The Unicode formatting controls reach whoever still has to read them. Both table
  backends sanitised a cell's line with the plain control sanitizer, which removes all of
  Unicode category C — and substitutes a space. That ran above the shaper and the
  algorithm: a ZWNJ between two Arabic letters did not merely go missing, it became a
  word break, and the letters the author had separated joined up anyway. Direction marks
  went the same way, so the PDF ran the algorithm over a different string than the one
  layout resolved the cell's direction from. Both now use
  TextControlSanitizer.removeExceptFormattingControls, as the paragraph pipeline does, and
  the controls are dropped at the glyph seam once their readers have run.
• PowerPoint needed a sanitizer of its own.sanitizeForRender is for a backend that
  draws glyphs; sanitizeForTextExport keeps the joining controls for one that shapes. A
  table cell is handed over as a whole logical line for PowerPoint to order as well, so
  the direction marks are part of its input too — PdfFont.sanitizeForLogicalTextExport
  keeps both classes, with the glyph fallback still applied to everything that draws.
• Existing left-to-right table content is unchanged. A cell holding bidirectional or
  Arabic text is not, and deliberately: what a declaration settles is the direction a line
  is embedded in, while a script runs the way it runs inside that whatever the base. So a
  cell that declared nothing is now shaped and ordered too, and its auto column measured on
  the joined forms — such a table moves, because what it drew before was the word backwards.

Verification

./mvnw -B -ntp clean verify → BUILD SUCCESS, 1963 tests, 0 failures (from 1938).
./mvnw -DskipTests -P japicmp verify -pl :graph-compose-core → BUILD SUCCESS against
the 2.0.0 baseline; the new record component on TableCellLayoutStyle keeps a delegating
constructor at the old arity.

+25 tests.

• RtlTableCellTest (PDF, 8) reads the glyph positions off the rendered page: Hebrew drawn
  reversed, AUTO answered per cell, one base direction for a whole multi-line cell, the
  direction-derived right edge, an explicit anchor winning over it, a Latin cell declaring
  nothing left exactly as it was, and a Hebrew cell declaring nothing reversed all the same.
• DocxTableCellDirectionTest (6) and the two new DocxRightToLeftTest cases assert
  w:bidi on the paragraph and w:rtl on the runs, that the text itself is handed over
  untouched, and that a left-to-right cell or paragraph writes the runs it always did.
• PptxTableCellDirectionTest (7) asserts the declared frame direction, logical text, that
  a bracket is left for PowerPoint to mirror rather than pre-swapped, and that a ZWNJ and
  an LRI/PDI pair both survive the hand-off.
• RtlTableCellTest.theJoiningControlsReachTheShaper measures what the page drew: the
  ZWNJ pair is wider than the naturally joined one, and the ZWJ pair is exactly as wide
  — asserted in both directions, because the defect made all three collapse to the same
  spaced-apart width.
• RtlScenariosVisualTest gains two scenarios, each pinned to both the coordinates and the
  pixels: a page holding an RTL table, an AUTO table and an undeclared control, and all
  five bundled scripts run through the cell path — Arabic and Hebrew declaring a direction,
  Georgian, Armenian and Korean held to not acquiring one.

All 105 examples regenerate; CommittedAssetDriftTest is green, with text-direction.pdf
and arabic-article.pdf refreshed — the first gains a table row showing the new call, the
second because its closing paragraph described the old limitation in Arabic prose.

Notes

• Cell alignment still reaches Word for no cell, right-to-left or not, so an explicit
  textAnchor is dropped there; the direction-derived edge arrives because Word's own
  default is the start of the flow. Column order in a right-to-left table is not mirrored
  (w:tblPr/w:bidiVisual unwritten). Both are recorded in the capability matrix.
• Lists in the DOCX export carry no direction at all — writeListLine writes neither
  property. Unchanged here.
• A copy out of a PowerPoint cell carries the brackets as typed, which the paragraph
  path cannot promise, since it mirrors before the hand-off.

Lane: canonical (document.table) + shared-engine (document.layout, three render
backends) — one public builder method, resolved once in layout, honoured per backend.