fix range checks bypassed by wraparound in number converters

[rootvector2]

the range checks in NumberConverter.toNumber(Class, Number) and in the byte/short/integer/long locale converters run on longValue()/doubleValue() of the source, but longValue() of a BigInteger or BigDecimal keeps only the low-order 64 bits and a double cannot represent 2^63 - 1, so out-of-range values wrap or round into range and convert to unrelated results (BigInteger 2^63 becomes Long.MIN_VALUE, 2^64 + 5 becomes Integer 5, and a locale-parsed "9223372036854775808" is clamped to Long.MAX_VALUE); found while checking the bounds from #404 against boundary values, fixed by comparing the exact value as BigDecimal before narrowing.

• 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.