fix(list-numbering): render hebrew1 and hebrew2 list markers

[Nathaniel-260]

Relates to #3933.

What changed

listIndexMap in shared/common/list-numbering/index.ts had no handler for the
OOXML hebrew1 and hebrew2 numbering formats, so generateOrderedListIndex
returned null and formatNumberingTemplate fell back to ''.

A Hebrew-numbered list therefore rendered with no number at all, in one of
two shapes depending on which branch of formatNumberingTemplate ran:

Branch	lvlText	Word	SuperDoc before	SuperDoc after
no levelNumberingFormats	%1.	א.	(nothing)	א.
with levelNumberingFormats (the v2 adapter path)	%1.	א.	.	א.

The failure was silent — review-aware-numbering still reported the paragraph
as resolved, carrying the empty marker — which is likely why it went
unreported.

This adds both formatters and registers them. Nothing else changes; the diff is
purely additive (219 insertions, 0 deletions).

Reproduction

Measured on the packed plugin build, real engine, headless Chrome, loading a
DOCX whose numbering.xml carries <w:numFmt w:val="hebrew1"/> and hebrew2:

Before — rendered text of the page:

i1  i2  i3  i4 … i16   SPLIT   i1  i2  i3 … i11

After:

א i1   ב i2   ג i3 … יד i14   טו i15   טז i16
SPLIT
‏א i1   ‏ב i2 … ‏י i10   ‏כ i11

The reproduction uses a generated DOCX fixture.

How the expected output was established

Not from the spec — from Word. ECMA-376 §17.18.59 names the two formats but
does not define their glyph rules, and Word departs from the obvious reading in
three places. Everything below was read out of Microsoft Word 16
(build 16.0.20326) via COM, from a DOCX carrying each format:
Range.ListFormat.ListString for list markers, Field.Result.Text for fields.
Over 2,500 markers in total.

1. Word represents only 1-392, then restarts from א.
Verified across three full periods of a 1200-item list (resets at items 1, 393,
785, 1177) and at the w:start values 0, 1, 380, 390, 391, 392, 393, 700, 780,
783, 784, 785, 32760 and 32767-32770 — the last of those lands in the 83rd
period, so the wrap keys off the counter value, not the item position.
Separately, all 392 representable values were measured for both formats and
match byte-for-byte, so the mapping is closed rather than sampled. Ruled out: a 3-letter cap (392 = שצב and 393 would be שצג, both
three letters), a 400 limit (ת never appears in hebrew1 at all), and an
item-count reset. 392 has no meaning in Hebrew numeration — the natural bounds
would be 399 or 400 — so it reads as an internal Word constant.

2. 15 and 16 are טו and טז, at every hundreds level.
יה and יו spell divine names and are avoided by convention. An exhaustive
diff of Word against naive gematria over all 392 values gives exactly eight
differences: 15, 16, 115, 116, 215, 216, 315, 316. Word does not extend the
courtesy to other sensitive combinations — 270 renders רע, 304 שד, 344
שמד — so neither do we.

3. Every hebrew2 marker carries a leading U+200F; no hebrew1 marker does.
Confirmed on two independent Word APIs. Word emits it once per formatted
number, not once per marker: a three-level hebrew2 marker %1.%2.%3 comes
back as U+200F א . U+200F ב . U+200F א. Placing the character inside the
formatter reproduces that exactly. Flagging this explicitly for review — it is
an invisible control character and byte-parity with Word was the deciding
argument, so say the word if you would rather it were dropped.

Also measured: no final forms (ךםןףץ) and no geresh/gershayim ever appear;
Word draws no marker at all for value 0.

Out-of-range contract

Values Word cannot number return '' rather than throwing. w:start="0" is
schema-valid and Word renders an empty marker for it, and 'ת'.repeat(-1)
would otherwise raise a RangeError inside the render path with nothing to
catch it. This matches the guards on intToAlpha, ordinalTextFormatter,
intToChineseCounting and the other neighbours in the file.

Why page numbering is not in this PR

The same 392 bound applies to the PAGE field path, but its overflow behavior
differs: Word substitutes a localized error string there instead of wrapping.
That is a separate decision and a separate public-API change, so it is a
separate PR.

Checks

• pnpm -r --filter @superdoc/common --filter @superdoc/word-layout … test — pass
• pnpm run check:types (tsc -b) — pass
• vp lint, vp fmt --check — clean
• New tests cover both formatNumberingTemplate branches, the טו/טז rule at all
  four hundreds levels, the wrap boundary, multilevel templates, the widest
  marker (18 characters), and the non-positive/non-integer contract.

Two notes from setting up, unrelated to this change

• pnpm test does not run on Windows: scripts/test.mjs:16 calls
  spawnSync('pnpm.cmd', …) without shell: true, which returns EINVAL on
  current Node (the CVE-2024-27980 fix). Same for
  scripts/check-public-docapi.mjs. Happy to send a one-line PR.
• CONTRIBUTING.md:89-95 scopes Bun to pnpm ci:local, but shared/common and
  packages/word-layout declare "test": "bun test", so plain pnpm test
  needs Bun too.

[qodo-code-review]

Qodo reviews are paused for this user.

Troubleshooting steps vary by plan Learn more →

On a Teams plan?
Reviews resume once this user has a paid seat and their Git account is linked in Qodo.
Link Git account →

Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center?
These require an Enterprise plan - Contact us
Contact us →

[cubic-dev-ai]

No issues found across 3 files

_{Re-trigger cubic}

[caio-pizzol]

Thanks for the thorough work here — this looks good.

We tested the exact PR locally and loaded DOCX fixtures through the current source runtime in Chromium. hebrew1 and hebrew2 render correctly, including RTL paragraphs and the leading U+200F for hebrew2. The decimal control still works too.

We’d keep U+200F for Word parity. We’ll handle the matching internal format support and release work on our side.

Approved from us. Thanks for the contribution!