refactor(engine): dedup the atomic-block page-admission guard

[DemchaAV]

Why

The atomic-block page-admission guard — reject if taller than a full page, advance to a
new page when it doesn't fit in the remaining height, mark the landing page touched — was
duplicated verbatim across three compile* methods (compileHorizontalRow,
compileStackedLayer, compileAtomicLeaf). Three identical copies of a load-bearing
pagination invariant are a drift risk: a future change to the admission rule has to land in
three places or they silently diverge.

What

• Extracted the guard into a private admitAtomicBlock(outerHeight, path, state); the three
  compile paths now call it after computing their block height.
• Byte-identical: same activeInnerHeight + CAPACITY_TOLERANCE reject, same
  remainingHeight + EPS new-page decision, same touchPage.

Tests

• ./mvnw -f aggregator/pom.xml verify -pl :graph-compose-qa -am — full compile + javadoc
  gate + the qa visual/parity byte-identity suite (643): green. Pagination and the
  too-large throw (PageCapacityToleranceDemoTest) are unchanged.

admitAtomicBlock mutates the compiler cursor (newPage/touchPage), so it stays a
LayoutCompiler private exercised by the qa corpus — not a pure isolatable helper (same as
the pagination-cursor helpers already on CompilerState). The guards that genuinely differ —
compileComposite's keep-whole / start-reservation logic and compileSplittableLeaf's split
loop — are intentionally left alone.