Reject out-of-range values in LongLocaleConverter

[rootvector2]

LongLocaleConverter.parse narrows the parsed number with result.longValue() and never range-checks it, so a value beyond long range like 99999999999999999999 is silently clamped to Long.MAX_VALUE instead of rejected: DecimalFormat returns it as a Double (the converter does not set parseBigDecimal) and Double.longValue() saturates. The sibling narrowing locale converters IntegerLocaleConverter, ByteLocaleConverter, ShortLocaleConverter and FloatLocaleConverter already reject out-of-range input, so LongLocaleConverter gets the same bounds check before narrowing. Found while auditing the locale converter family against those sibling checks.

• Read the contribution guidelines for this project.
• Read the ASF Generative Tooling Guidance if you use Artificial Intelligence (AI).
• I used AI to create any part of, or all of, this pull request. Which AI tool was used to create this pull request, and to what extent did it contribute?
• Run a successful build using the default Maven goal with mvn; that's mvn on the command line by itself.
• Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied. This may not always be possible, but it is a best practice.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Each commit in the pull request should have a meaningful subject line and body. Note that a maintainer may squash commits during the merge process.

[garydgregory]

Hello @rootvector2
Please use assertThrows. Also port to the 1.X branch ;)

[rootvector2]

Done. Switched the test to assertThrows and pushed. 1.X port is up as #407.

[garydgregory]

This is unrelated, but could you have a go at fixing the test in Java 25 and up? There are failure in SQL related classes. TY!

[rootvector2]

Took a look. The failures are the two testLocale cases in SqlTimeConverterTest and SqlTimestampConverterTest. CLDR (JDK 20+) switched the US SHORT time format to a narrow no-break space (U+202F) before AM/PM, and the tests hard-coded a regular space. Fix is in #410 — it derives the separator from the JVM's own format so it passes on both old and new JDKs. Verified failing/passing on OpenJDK 26, full suite still green on 21.