fix(layout): take a margin off once between measure and placement

[DemchaAV]

Why

A node's margin was subtracted twice between the two passes that lay it out, in two unrelated places, because the seam between them was never written down.

A row band is sized by NodeDefinitionSupport.measureRow, which prepares each child inside its slot less that child's own margin, then placed by LayoutCompiler, which prepares it again. The placement pass handed prepareForRegionWidth a width the margin had already been taken out of — and that helper subtracts the margin itself. The child was laid out at slot - 2 * margin against a band measured from slot - margin, wrapped into a line the band had no room for, and the row's own guard rejected the document it had just measured:

IllegalStateException: Row 'ContainerNode[0]/Band[0]' child 'SectionNode'
measured height 77.7000023983419 exceeds row inner height.

Only that one path throws. The same disagreement is silent in placeRowBandInFixedSlot (a row in a LayerStack layer or a composed table cell), which has no inner-height guard: the tallest child is seated above its band and spills through the top under a non-TOP verticalAlign. And compileNodeInFixedSlot always derived its own region as slot - margin, so a composite row child reported one width while its own children were laid out in another.

A multi-angle review of that fix found the same defect class one layer away, in composed table cells, and it is fixed in the second commit. DocumentTableCell.node(...) measured its content at the cell's full inner width with the margin left in; the fixed-box walk then removed it. On a 260pt column a section with a 20pt side margin measured 3 lines and drew 4, painting 8.95pt below its own table while its box, still carrying the wider measured width but shifted right by margin.left, reached 295.34 against a cell edge of 280. Vertically it failed the other way: the cell height ignored the margin outright while placement still applied margin.top, dropping the content 16.00pt through the cell floor. On a leaf child the margin was discarded entirely.

What changed

• LayoutCompiler — both row-seating loops pass the whole slot to prepareForRegionWidth and let childAvailableWidth perform the single subtraction. That is the contract the other five callers already used: each passes a region with only the parent's margin and padding removed. The clamp is unchanged — the removed Math.max at the call sites is the same one the helper still applies.
• prepareForRegionWidth / childAvailableWidth — now carry Javadoc stating that the argument is the region the node's margin box occupies. The undocumented contract is what let one bug exist in two places.
• TableLayoutSupport — a cell's inner box is the content's margin box, the same contract a row slot uses: prepareComposedCellContents measures inside the margin and naturalCellHeight reserves it on the vertical axis.
• NodeDefinitionSupport.emitComposedCellFragments — places the content one margin in on both axes, and computes the anchor slack against the content's outer height.
• DocumentLayoutPassContext.emitCompositeSubtree — a FragmentPlacement is a content box (both callers, the composed cell and ChartDefinition, build one at the exact rectangle and pass Margin.zero()), but the fixed-box walk reads a margin box. The bridge now converts between the two. Every conversion is an identity at zero margin, so nothing shipped today moves a point.

Behaviour change. Output moves only for a row child, or composed cell content, that carries a margin — it now occupies the room reserved for it instead of a smaller box. Content without a margin is untouched; the arithmetic is identical at zero.

Verification

./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 → BUILD SUCCESS, 2043 tests, 0 failures, on this branch rebased onto current develop. Knowledge surfaces, claims and routes all current.

• RowChildMarginWidthTest (5) — the width base read back out of the placed node at each row-seating site; a composite row child's own width against the region its children were given; the fixed-slot child kept inside its band; and the reported repro. Verified fails-closed per hunk: reverting the page-level site alone turns three red, reverting the fixed-slot site turns the other two red.
• ComposedCellMarginTest (3) — a horizontal margin must not push content below its own table, a vertical margin must be reserved by the cell, and a leaf child's margin must not be discarded. All three fail on the unfixed engine.

Assertions are containment and derived widths rather than absolute coordinates, so none depends on a font metric.

No layout snapshot, pixel baseline or committed preview moves. Independently established three ways: 154 row children across the 64 committed layout snapshots, 124 across all 33 shipped presets, and a full PlacedNode/PlacedFragment dump of those presets under both engines that diffs empty. Nothing in the templates, the examples or the fixtures puts a horizontal margin on a row child, or a margin on composed cell content — which is also why neither gate caught either bug.

Lane: shared-engine — layout compiler and table measurement; no public API surface changed (document.layout is @Internal at package level, and LayoutCompiler is excluded from the knowledge surfaces).

Known gaps, deliberately not in this PR

• placeRowBandInFixedSlot still has no inner-height guard. Adding the throw is a behaviour change for documents that currently overflow silently, and the state it would catch was only reachable through the composed-cell bug fixed here.
• The row seating loop is duplicated between the page-level path and placeRowBandInFixedSlot — it was created by copying that loop, carrying the double subtraction with it, which is why this one-line fix had to be applied twice. Extracting it is the durable fix and belongs in its own PR.