feat(engine): keep a heading with the first slice of a table or list below it

[DemchaAV]

Why

keepWithNext() relocated a stranded heading only when the block below it started
with a paragraph. LayoutCompiler.leadingUnitHeight returned a true first-line lead
for a paragraph but the whole outer height for every other leaf — including
SPLITTABLE tables and lists. So a keep-with-next heading directly above a
page-spanning table(...) or list computed needed = heading + wholeBodyHeight,
which exceeds the page; the guard needed <= activeInnerHeight() failed and the
heading stayed put — the exact orphan keepWithNext() exists to prevent, just one
body kind short of working.

What changed

• New seam NodeDefinition.firstSliceHeight(PreparedNode<E>) (@Beta/@Internal
  SPI). The default returns the whole measured content height, so a truly atomic leaf
  (image, chart, shape) is kept whole — the previous behaviour. leadingUnitHeight's
  leaf branch now delegates to it, so each leaf's split granularity lives in its own
  definition instead of an instanceof switch in the compiler.
• Paragraph override returns its first visual line — the instanceof PreparedParagraphLayout logic moves out of LayoutCompiler into
  TextFlowSupport.paragraphFirstSliceHeight.
• Table override (NodeDefinitionSupport.tableFirstSliceHeight) returns its
  repeated header rows plus first body row. This mirrors splitTable's minimal head,
  which requires rowCount > headerCount, so the smallest slice it will place is the
  repeated header rows plus one body row; with no repeated header it is the first row.
• List override returns its first item (TextFlowSupport.listFirstSliceHeight),
  the same value splitList uses for the first placeable unit.
• Gated behind keepWithNext() (off by default), and leadingUnitHeight runs only in
  that lookahead — so layouts that do not opt in are byte-identical. The default's
  whole content box already includes the leaf's own padding, so the caller's added top
  reservation slightly over-reserves for a padded atomic leaf; harmless, since it
  only makes an already-indivisible block a touch more eager to relocate, and the value
  gates a page break, never geometry.
• CHANGELOG and docs/recipes/keep-together.md now describe the first slice across
  paragraph, table, and list bodies (previously they said non-paragraph bodies were
  kept whole).

Verification

./mvnw -B -ntp clean verify across core + render-pdf + templates + testing + qa →
BUILD SUCCESS. Core 392 green (incl. PublicApiNoEngineLeakTest,
PublicApiSinceTagCoverageTest); qa 651 green; render-pdf 120 green; javadoc
gate clean.

SectionKeepWithNextTest grows 6 → 8 — two new tests mirroring the existing
paragraph case:

• relocatesHeaderBasedOnFirstSliceOfPageSpanningTable — header flush at a page bottom
  above a page-spanning table (with a repeated header row); asserts the header
  relocates onto the table's start page when opted in, and strands (header page < table
  page) when not.
• relocatesHeaderBasedOnFirstItemOfPageSpanningList — the list counterpart.

Both fail without the production change (the whole-height default keeps needed > activeInnerHeight, so no relocation fires).

Lane: shared-engine — layout/pagination seam; no public authoring surface touched.

Merge order: stacked on #426 (base feat/keep-with-next); merge after #426, or
retarget to develop once #426 lands.