Add consumer compatibility CI across supported JDKs and all published JARs

Follow-up to #90 (reviewed at 31588e1). This tracks work intentionally kept separate from the modernization PR.

Why

The checked-in CI builds and tests on JDK 17 only. #90 adds packaged-core OSGi R6 and module-discovery tests, but equivalent coverage for all four artifacts and actual Java 8 runtime compatibility remains incomplete.

The review checked core consumer execution on JDK 11/17/21/25 and Java 8 class-file versions; it did not execute on Java 8. Past issues #79 and #81 demonstrate why compilation and ordinary unit tests alone are insufficient.

Acceptance criteria

• Build artifacts with the supported build JDK, then run separate consumer tests on the supported runtime matrix, including an actual Java 8 runtime. Do not attempt to run the modern build toolchain or incompatible test-app dependencies on Java 8.
• Document runtime support per artifact and use appropriate servlet/JSP/ESAPI dependency versions in each fixture.
• Exercise classpath, explicit JPMS, automatic-module fallback, and legacy/current OSGi consumption where applicable; include real encoding/tag/adapter calls.
• Add artifact-level assertions for all four JARs: automatic module names, explicit descriptors, OSGi identities/imports/exports, multi-release layout, bytecode/API baseline, TLD resources, and absence of test dependencies in published runtime contents.
• Keep consumers isolated from reactor test classpaths so missing packaged classes or dependencies cannot be masked.
• Keep the Docker/Selenium test app on its own compatible JDK/container job and keep failure diagnostics available.
• Coordinate adapter module-path tests with the separate JPMS-readability fix; document known limitations rather than presenting descriptor discovery as successful adapter execution.

Preserve the intentionally different published automatic and explicit module names documented in #90.

Commencez par lire l’issue #90 et examiner le commit 31588e1, puis inspectez la CI versionnée dans le dépôt ainsi que la couverture existante des consumers packagés. Faites correspondre les quatre JAR publiés avec la matrice des runtimes JDK pris en charge, l’application de test Docker/Selenium et les vérifications listées concernant le classpath, JPMS, OSGi, le bytecode, les ressources et les dépendances. Le travail est considéré comme terminé lorsque des jobs de consumers isolés couvrent les critères d’acceptation et documentent les limitations connues des adapters.