fix(pagination): split oversized tables whose only merges are horizontal

[JSv4]

Supersedes #808 (from a fork, so review changes couldn't be pushed there). Fixes #807. The contributor's commit is carried unchanged with its authorship; one review commit is added on top.

The problem

In the paginated view, a table taller than one page is split between rows so it can flow across pages. The splitter refused any table containing a colspan. A refused table falls back to a single page box that clips its overflow, so every row past the first page-height is rendered but invisible. The shape this hurts most is common in legal documents: a long table whose section-header rows span every column (Word's w:gridSpan). The reporter's document hid 17 of its 25 rows. Word shows it across 6 pages.

Why the change is safe

A colspan merges cells side by side within one row. The splitter only cuts between rows and copies whole rows into each page fragment, so it can never cut through a colspan. Vertical merges (rowspan) genuinely can span a cut, so tables with them still take the old fallback, along with nested tables and footnotes. Each fragment is still measured, and the old fallback is used if any fragment doesn't fit.

Review findings

• Column alignment across page fragments. I checked the one real risk: a continuation fragment whose first row is a full-width header row. I used a probe on real converter output (every row but one in seven made full-width, with a page break forced onto a spanning row).
  • Tables with the <colgroup> the converter emits from Word's column grid kept identical column widths in every fragment.
  • Only a fixed-layout table with no colgroup lost its column widths in that fragment (columns went equal-width). The converter omits the colgroup only when a grid column has a missing or zero width, and the old behaviour for such a table was hiding rows, so this isn't a blocker. It's noted here rather than guarded against, because a guard would bring the clipping back.
• Test tightened. The new test only checked that some colspan survived. That would also pass if the header row were duplicated across fragments or rendered with the wrong span. It now asserts exactly one spanning cell, spanning every column.
• CHANGELOG. Added the missing ### Fixed entry, which the repo requires for bug fixes.

Validation

• TDD check: with [colspan] put back into the reject selector, the new test fails (1 table fragment where more than 1 is expected). With the fix it passes. The rowspan and plain-table tests pass either way.
• All 76 pagination-related Playwright tests pass locally (Chromium): the pagination groups in docxodus.spec.ts plus every pagination-*.spec.ts.
• tsc --noEmit is clean.
• fix(pagination): split oversized tables whose only merges are horizontal #808's own CI was green on every job.

🤖 Generated with Claude Code

https://claude.ai/code/session_01EuVfv22yFAxchW5H2F7Sk9

---

Generated by Claude Code

[github-actions]

Thank you for your submission, we really appreciate it. Like many open-source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution. You can sign the CLA by just posting a Pull Request Comment same as the below format.

---

I have read the CLA Document and I hereby sign the CLA

---

_{You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot.}

[JSv4]

cla check is failing, and it can't be fixed from this PR's code.

The CLA workflow (added to main in #812, after #808 was opened) now runs on this PR. It flags commit b38ab93 by Karlei Kongsiri (@karlei-irving), the original fix carried over from #808. Every other author here is on the allowlist.

Only the contributor can sign their own CLA, so this is waiting on them. They can post the signature line from the bot's comment above on this PR. Because the bot records signatures per GitHub user, that one signature should also cover #808. After that, a recheck comment re-runs the check.

The alternative is to re-author the commit so the check passes. I haven't done that: it would take attribution away from the contributor and sidestep the CLA's purpose. Everything else on this PR's previous head was green. CI on the new head (f2fe40c, which merges main at v12.6.3) is still running.

---

Generated by Claude Code