build: add maven-enforcer-plugin with Java/Maven/plugin-version rules (E2)

[DemchaAV]

Summary

Wires up Track E2 from the v1.6.5→1.7 readiness taskboard. Binds three maven-enforcer-plugin rules to the validate phase so the build refuses to even start when a precondition is broken.

The three rules

Rule	Setting	What it catches
requireJavaVersion	[17,)	A maintainer who tries mvn under JDK 11 or 15 — "works on my Java 21" drift.
requireMavenVersion	[3.8.0,)	The oldest version the planned central-publishing pipeline (Track D3) supports — older Maven resolvers don't ship the relocation handling Central needs.
requirePluginVersions	banLatest=true banRelease=true banSnapshots=true	Every plugin must declare an explicit non-LATEST / non-RELEASE / non-SNAPSHOT version. Generalisation of the PR-7.1 exec-plugin drift lesson — any unpinned plugin is a future drift.

All three values live in <properties> (enforcer.requireMavenVersion, enforcer.requireJavaVersion, maven.enforcer.plugin.version) so they sit at the top of the file and bump together.

<pluginManagement> block

Maven's default lifecycle binds five plugins implicitly (clean, install, site, resources, deploy). requirePluginVersions would otherwise flag every one of them. Pinned in a new <pluginManagement> section to the versions Maven 3.9.x currently resolves out of the box:

Plugin	Version
maven-clean-plugin	3.4.0
maven-install-plugin	3.1.4
maven-site-plugin	3.21.0
maven-resources-plugin	3.3.1
maven-deploy-plugin	3.1.4

The explicit pin stops a future Maven upgrade from silently shifting the plugin set we build against.

Verification

$ ./mvnw -B -ntp validate -pl .
[INFO] Rule 0: org.apache.maven.enforcer.rules.version.RequireMavenVersion passed
[INFO] Rule 1: org.apache.maven.enforcer.rules.version.RequireJavaVersion passed
[INFO] Rule 2: org.apache.maven.enforcer.rules.RequirePluginVersions passed
BUILD SUCCESS

Pre-pin, Rule 2 caught the five default plugins listed above — confirming the rule actually works. Post-pin, all three green.

Reactor validate green:

$ ./mvnw -B -ntp -f aggregator/pom.xml validate
[INFO] GraphCompose Examples ... SUCCESS
[INFO] GraphCompose Benchmarks ... SUCCESS
BUILD SUCCESS

Full suite re-run:

$ ./mvnw -B -ntp test -pl .
BUILD SUCCESS (~50s)

CHANGELOG entry added to v1.6.6 — Planned under ### Build.

Why this scope

• Three rules, not five. dependencyConvergence and banDuplicateClasses are commonly violated by transitive deps that don't impact runtime; they'd add noise without catching real bugs at this stage. Easy to add later if a specific drift incident motivates it.
• validate phase, not verify. Validate runs before compile, so a broken precondition fails fast — typically inside 1 second. No reason to wait for tests to discover that the JDK is wrong.
• No subordinate-module activation. The plugin is declared on the library root pom; examples/pom.xml and benchmarks/pom.xml inherit from the graphcompose-build aggregator, not the library root, so enforcer doesn't run twice. Intentional — only the library has the precondition contract.

Test plan

• ./mvnw validate -pl . green
• Reactor validate green
• Full suite still green (~50s)
• CI green on PR (Guards / JDK 17/21/25 / Examples Smoke / binary-compat / no-poi-suite)
• Reviewer skim of the enforcer block (~30 LOC) and the <pluginManagement> block (~25 LOC) — the only load-bearing parts
• (Out of scope) follow-up: dependencyConvergence rule when (and if) a transitive-version drift surfaces in production