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.

Start with esapi/pom.xml and the ESAPI adapter tests, then review #90 and the historical issues #31, #63, and #74. Define the fixed stable baseline, compatibility claims, and override mechanism before changing the adapter scope. Done means tests cover the claimed versions and fresh-cache builds and published POMs select the same intended stable dependency without an unintended range or prerelease.