fix(docx): leave a row's hang on its page when a spacer opens the next

[DemchaAV]

Why

Follow-up to #827. A row whose cell's last line hangs past the row now leaves that reach in hangingBelow, to come out of the gap under the row.

A spacer the layout moves to the next page took it from the wrong space. The spacer's newBodyParagraph took the reach out of the space above it. Only then did holdTheGapAboveInTheLine move what was left of that space into the spacer's line, which holds the gap the layout carries onto the new page.

• The row's reach is on the page above, but it shortened the gap held on the new one.
• In a row whose last contact line hangs 1.85pt, a 10pt gap carried to the next page was held as 8.15pt, and everything on that page stood 1.85pt high.
• A paragraph moved to a new page (holdAParagraphsTopEdgeOnItsPage) already leaves the hang, a pull and a card's border below on the page above. A table there leaves the hang and the border.

The Linux LibreOffice baseline was not rewritten in #827.

What changed

• writeSpacer. For a body spacer that starts a page of its own, the hang, the pull and borderBelow are cleared before its paragraph is written, as on the paragraph path. Unlike that path, they are cleared even when the spacer's line then holds none of the gap: they belong to the page above either way.

• cellOverhang's comment says which writers read it: only a row does. A panel or a stack written as columns still makes its table taller by the remainder.

• Baselines. libreoffice-linux and its -lines file are taken from fix(docx): take a cell's last line hanging past its row out of the gap under the row #827's CI run (docx-fidelity-37117164489). It moves the same three documents as Windows LibreOffice, by the same amounts:

  • TimelineMinimal: median 1.40 → 0.45pt;
  • its letter: 1.32 → 0.33pt;
  • VioletGrid: 5.71 → 5.21pt.

  No line is lost, page counts are unchanged, and no line moves more than 0.22pt further from the page. This PR's own CI measurement is identical to that baseline.

• Docs. CHANGELOG.md, in fix(docx): take a cell's last line hanging past its row out of the gap under the row #827's entry.

Verification

• New tests in DocxRowOverhangTest. The block above is measured first, then a filler is sized so that it ends 3pt above the page's foot, under the 10pt gap. Each test first checks on the layout that the spacer opens page 2 with 10pt above it.
  • aRowsHangStaysOnItsPageWhenTheGapUnderItCarriesASpacerToTheNext: a row whose last line is held exact to its icon. The spacer holds the hairline and the whole gap, 202 twips. With the hang left in place it holds 165.
  • aPullOutOfTheBlockAboveStaysOnItsPageWhenTheGapCarriesASpacerToTheNext: a paragraph with a −4pt bottom margin. The spacer holds 202 twips; with the pull left in place, 122.
• Template corpus, re-measured in both editors on Windows: unchanged, line for line. No template sets a hanging row right before a spacer the layout carries to a new page.
• 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. render-docx runs 841 tests, qa 1814.

Known limits

• A row's hang is not taken from the gap above an overlay band that follows it. The band's first block resumes the band's own spacing and forgets the hang. Text hanging below a line pair is treated the same way. This was already so before fix(docx): take a cell's last line hanging past its row out of the gap under the row #827.

Lane: shared-engine (render-docx). No public API change.