build: add graph-compose-core; keep graph-compose as a drop-in wrapper

[DemchaAV]

Why

The 2.0 module split originally aimed to make bare graph-compose the lean core —
which would make every existing consumer's .buildPdf() throw
MissingBackendException at runtime after upgrading to 2.0. This reverses that:
the engine gets its own graph-compose-core coordinate, and graph-compose stays a
drop-in that keeps rendering PDF, so existing consumers upgrade with zero changes.

What

• Rename the root artifact graph-compose → graph-compose-core — the engine
  sources stay at the root dir, only the coordinate string changes.
• New wrapper/ module publishes the graph-compose coordinate as an empty
  jar (jar, not pom — a pom would force consumers to add <type>pom</type> and
  break their build) that depends on graph-compose-core. A graph-compose
  dependency now brings the engine transitively and renders PDF unchanged.
• Repoint the engine-internal modules that need the engine classes directly
  (render-docx, testing, qa, benchmarks — incl. the tests-classifier jar) to
  graph-compose-core. bundle and examples stay on graph-compose (the wrapper),
  dogfooding the consumer path.
• Wire the aggregator (+wrapper), CI (build gate targets graph-compose-core; the
  examples job installs the wrapper), publish (deploy the wrapper after the core),
  cut-release.ps1 (bump/commit/install the wrapper), jitpack (build both
  coordinates), and VersionConsistencyGuardTest (wrapper tracks the engine version).
• Core still carries the PDF backend and the templates; those move into their own
  modules over the rest of the 2.0 cycle. Consumer imports are unchanged.

Tests

• Full reactor ./mvnw -f aggregator/pom.xml clean verify → BUILD SUCCESS, all 11
  modules, all tests green (incl. the wrapper-aware version guard).
• Back-compat proof: graph-compose dependency tree resolves to
  graph-compose → graph-compose-core (compile); the examples module (which depends
  on the graph-compose wrapper) renders 85 example PDFs.