test(qa): hold every template's DOCX export to a Word baseline

[DemchaAV]

Why

The DOCX fidelity gate (#805, #807) holds the export to LibreOffice's setting of it. Word is the editor the export answers to, and it sets text differently from LibreOffice: a sidebar CV LibreOffice sets 3pt off throughout stands where the page puts it in Word. CI cannot run Word, so nothing held the export to Word's setting.

What changed

• DocxFidelityCorpusTest has two more modes, export and word, besides libreoffice.

  • export writes each preset's PDF and DOCX, and stops.
  • word measures Word's PDFs in target/docx-fidelity/word against word-windows.tsv. It first re-exports every document, and measures a document only when the SHA-256 its conversion recorded is that of the DOCX this tree exports (WordConversion). A conversion left from another tree fails and names the documents that changed; it is not measured in the new tree's place. A missing conversion.json, or one naming no Word build, is refused.
  • A mode the test does not know fails, rather than being skipped. libreoffice and export clear engine/ first, so a preset no longer in the corpus leaves no DOCX behind.

• scripts/docx-visual/word-fidelity.ps1 runs the three steps:

  1. export;
  2. the existing convert-with-word.ps1, through a private hidden Word instance that records its version;
  3. word, with -Update to rewrite the baseline.

  Run it from PowerShell (pwsh). Word driven through COM from a process Git Bash started has stalled on its first document, so Word is not driven from the build.

• convert-with-word.ps1 records each DOCX's SHA-256 beside its PDF, and repaginates before it exports, as Word settles pagination on screen.

• word-windows.tsv / -lines.tsv: the Word baseline, taken with Word 16.0 (16.0.20430). It holds 4,154 of the corpus's 4,328 lines; 322 drift past 2pt. OrangeOps is set on 2 pages against the page's 1.

• Docs. CONTRIBUTING.md says to run the script before a DOCX export change is opened. CHANGELOG.md has a Tests entry.

Verification

• DocxFidelityGateTest (18 tests, +2). A conversion record written as convert-with-word.ps1 writes it (UTF-8 with a BOM, an upper-case digest) reads back its build. It matches the DOCX exported again, and not one with a byte changed or a document it never converted. A missing record, or one with no build, is refused.
• Two runs of the script measure the same: the second measures, to the hundredth, what the first wrote as the baseline.
• Reverting fix(docx): stand NavySidebar where the page sets it in Word — placed picture size, ring set-in, header margin, list sides #802's rule that a list's own margin indents its items:
  • export, then word with no new conversion, fails on the document Word converted from other DOCX: ["cv-navy_sidebar"].
  • The full script fails cv-navy_sidebar: 2 lines are no longer found ("increased website traffic…", "strategy.").
• libreoffice mode still passes against its baseline. With no mode set, the corpus test is skipped; -Dgraphcompose.docxFidelity=Word fails.
• Full reactor gate: ./mvnw -B -ntp clean verify -pl :graph-compose-core,:graph-compose-render-pdf,:graph-compose-render-docx,:graph-compose-render-pptx,:graph-compose-templates,:graph-compose-testing,:graph-compose-qa,:graph-compose-coverage -am gives BUILD SUCCESS (qa 1811).
  • After install, examples run 93 green.
  • The knowledge checks pass.

Known limits

• It runs on a Windows machine with Word, by hand. CI holds the LibreOffice baselines only.
• OrangeOps is barely held. Word sets it on 2 pages and finds 6 of its 108 lines: 102 of the 174 lines the baseline does not hold.
• The baseline is one Word build's setting. Another build may set some lines a little apart, and its note names the build to tell such a run from a regression.

Lane: test (qa) and scripts.