build(api): add japicmp binary-compatibility gate vs v1.6.5 (E1)

[DemchaAV]

Summary

Wires up Track E1 (japicmp baseline=v1.6.5) from the 1.6.5→1.7 readiness taskboard — the foundation 1.6.6's Maven Central debut and 1.6.7's dependency cleanup depend on.

• pom.xml — new japicmp profile carrying japicmp-maven-plugin and a profile-local JitPack <repositories> (downstream consumers do not inherit it). Versions pinned in properties: japicmp.version=0.23.1, japicmp.baseline=v1.6.5. Plugin binds its cmp goal to the verify phase.
• .github/workflows/ci.yml — new binary-compat job, PR-only, runs after the guards job. Uploads the report directory as an artifact for inspection on red runs.
• CHANGELOG.md — opens ## v1.6.6 — Planned with a Build subsection.

Why

Without a structural binary-compatibility gate we cannot promise zero breaking — which is the whole point of the v1.6.6 Maven Central debut. JitPack consumers tolerate accidental breaks (you bump and find out); Central consumers do not, and japicmp-maven-plugin against a published baseline is the standard fix.

Pinning the baseline at v1.6.5 specifically: it's the freshest published artifact, ships through JitPack today, and is the canonical "what users currently see" surface. Each subsequent patch release will keep <japicmp.baseline> pointed at the previous public tag.

Policy

Knob	Setting	Reasoning
breakBuildOnBinaryIncompatibleModifications	true	An unintended binary break = hard fail. This is the gate's whole job.
breakBuildOnSourceIncompatibleModifications	false	Phased — we'll tighten after 1.6.6 cut. Avoids tripping on Javadoc-only or signature-clarification churn while the policy beds in.
onlyModified	true	Don't re-emit unchanged classes in the report.
includeSynthetic	false	Compiler-generated bridge methods aren't part of the contract.

Reports land in target/japicmp/ as HTML / MD / XML / diff. The CI artifact upload is the audit trail for any red run.

Verification

Local run against current develop:

$ ./mvnw -B -ntp -DskipTests -P japicmp verify -pl .
[INFO] --- japicmp:0.23.1:cmp (japicmp-against-baseline) @ graphcompose ---
[INFO] Written file '.../target/japicmp/japicmp-against-baseline.diff'.
...
[INFO] BUILD SUCCESS

Report contents:

Comparing source compatibility of graphcompose-1.6.5.jar against GraphCompose-v1.6.5.jar
No changes.
Semantic versioning suggestion: 0.0.1

(Expected — develop is bit-identical to v1.6.5 at the jar level fresh after the release; the cut-release-script fix-up PR-83 only touched scripts/ and docs/.) The next PR that touches the public surface will exercise the gate end-to-end.

Guards re-run after pom changes:

$ ./mvnw -B -ntp test -Dtest=VersionConsistencyGuardTest,CanonicalSurfaceGuardTest,DocumentationCoverageTest -pl .
[INFO] Tests run: 18, Failures: 0, Errors: 0, Skipped: 0

Test plan

• mvn -P japicmp verify zelёный locally
• Guards (Version/CanonicalSurface/DocumentationCoverage) unchanged
• PR CI green — the new binary-compat job is the live gate
• Reviewer skim of the profile config (JitPack repo scoping, plugin policy)
• Next public-surface PR exercises the gate end-to-end (out of scope here)