fix(docx): keep the layout's grid, row heights and unbroken rows for a table with side padding

[DemchaAV]

Why

The page draws a table's rows inside its padding: NodeDefinitionSupport.prepareTable measures the table at finalWidth + padding.horizontal, and lays each row out padding.left in, finalWidth wide. DocxLayoutMetrics.ownRows and tableColumns matched a table's rows to the layout by the table's placement width. A table with side padding therefore matched none of its rows, and the DOCX export wrote it:

• without the layout's grid or a fixed layout, so Word re-fitted its columns;
• with no row heights;
• with rows Word could break across a page;
• with the drawings in its cells anchored outside its rows;
• standing its left padding left of where the page draws its rows.

The report named the left padding; the grid, row heights, unbroken rows and anchors it did not.

What changed

• DocxLayoutMetrics.rowsWidth is the placement less the side padding, and ownRows and tableColumns measure a table's rows against it. Row heights, unbroken rows, cell boxes and the grid come back for a table with side padding.
• The padding holds a table in as its margin does. writeTableWithItsOwnSpacing adds a table's side padding to the insets it is written between: its left side is in w:tblInd, and both are out of the room its columns are given. A row's padding is unchanged, since it rides in its cells' margins (writeRow).
• withEditorSlack no longer takes the padding off the room a second time; it is among the insets now.
• The report no longer names a table's left padding, since it is written. DocxNodeFieldLedgerTest moves TableNode.padding to WRITTEN; 22 node-field gaps remain.
• The CHANGELOG, the recipe (Tables and Composed cells rows, and the indent a table is written at) and the capability matrix's nested-table width say so.

Verification

• ./mvnw -B -ntp install -pl :graph-compose-render-docx → BUILD SUCCESS: 1014 tests, 0 failures, 1 skipped (the property-gated fidelity probe).
• DocxPaddedTableTest is new, 7 tests:
  • a table of fixed columns with side padding is written as one with those side margins: the body XML is equal, with the layout's fixed grid, cantSplit, the row heights and the indent;
  • the same for a table of auto columns;
  • an auto column takes the slack the room inside the padding leaves, where the padding counted twice would leave none;
  • a table composed in a cell is held in by its padding there (w:tblInd of 15pt);
  • a table under an alignment wrapper is written as a margined one there too;
  • a drawing a padded table's cell is all of is anchored in that cell, as in a margined table;
  • a table with padding on every side gets no report note.
• The tests fail without the code they cover. With the rows measured against the placement again, the five equality tests fail. With the padding counted twice in the slack, the slack test fails on its own. With the padding left out of the insets, the composed-cell test fails.
• The corpus does not change. No template gives a table side padding: the 62 corpus documents exported deterministically are byte-identical to the export before the change (DocxFidelityCorpusTest -Dgraphcompose.docxFidelity=export, SHA-256 per file, 0 of 62 differ). A table with side padding is written as one with those margins, which the corpus already holds.
• Documentation and qa DOCX tests:
  • -pl :graph-compose-core -Dtest='com.demcha.documentation.**' → 166 tests, 0 failures;
  • qa documentation guards plus DocxPageZoneTest, DocxTransparentWrapperTest, TimelineRailAcrossBackendsTest and RtlAcrossBackendsTest → 52 tests, 0 failures.
• The full reactor gate was not run; no public API, POM or workflow file changed.

Lane: render-docx backend (what a table with side padding is written as) plus tests and docs.