Replace the ESAPI version range with a deterministic, tested dependency policy

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

Problem and evidence

esapi/pom.xml declares org.owasp.esapi:esapi:[2.5.1.0,3). During the review this resolved to 2.7.0.1-RC1, meaning a fresh build can select a prerelease without any repository change. The range is also part of the published consumer POM.

Related historical failures from changing ESAPI APIs or resolution: #31, #63, and #74. This issue is not a claim that the currently resolved release is vulnerable.

Acceptance criteria

• Select and document a supported, fixed stable ESAPI baseline; retain a deliberate override mechanism if needed.
• Document the supported ESAPI compatibility range separately from Maven's dependency selection.
• Add build/runtime tests for the selected baseline and any other versions claimed as supported, including delegated adapter methods.
• Validate dependency convergence and the security/runtime implications of the transitive graph; preserve compatibility claims or explicitly document any necessary change.
• Confirm fresh-cache builds select the same intended stable dependency.
• Verify the generated/published POM does not retain an unintended open-ended range or prerelease selection.
• Coordinate the chosen dependency/module identity with the separate JPMS adapter issue.

Limit changes to the ESAPI adapter and its tests/documentation; do not add ESAPI dependencies to the core encoder.

Commencez par esapi/pom.xml et les tests de l’adaptateur ESAPI, puis examinez #90 ainsi que les issues historiques #31, #63 et #74. Définissez la base stable fixe, les affirmations de compatibilité et le mécanisme d’override avant de modifier le périmètre de l’adaptateur. C’est terminé lorsque les tests couvrent les versions revendiquées et que les builds avec un cache vierge ainsi que les POMs publiés sélectionnent la même dépendance stable prévue, sans plage ni version prerelease involontaire.