Extract backend-neutral font measurement so DOCX and PPTX stop depending on render-pdf #441

Opening a DocumentSession resolves a FontMetricsProvider so text can be measured, and graph-compose-render-pdf is the only artifact that publishes one. Two consequences reach consumers today:

DOCX is not installable on its own. render-docx/pom.xml declares render-pdf at test scope — enough for the module's own suite, which builds a session to exercise the exporter. A consumer who installs graph-compose-core + graph-compose-render-docx fails at create() with MissingBackendException before any export runs. Surfaced by the new s8-core-render-docx release-smoke scenario, which is why that scenario pins core + render-docx + render-pdf. Documented as a requirement in render-docx/README.md for 2.1.0.

PPTX drags in the whole PDF stack. render-pptx declares render-pdf at compile scope deliberately — it reuses the PDF font-measurement library so glyph widths stay aligned with the widths that produced the layout graph, and it re-renders through the PDF backend for the clip raster fallback. The measurement half of that coupling is not inherent; the raster half is. So "install exactly what you render" is not fully true for either POI backend.

Extracting the font-measurement seam into its own artifact (or shipping a default provider in core) would let a DOCX consumer install two coordinates and a PPTX consumer avoid PDFBox except when clipping actually rasterises.

Not a 2.1.0 blocker: both combinations work once the PDF backend is present, and that is now documented and covered by release smoke. Raising the dependency scope in render-docx was considered as a quick fix for 2.1.0 and rejected — it would widen every DOCX consumer's tree while leaving the underlying coupling in place.

Related: the roadmap's "Backend-neutral layout measurement" item.