NumberConverter.toNumber(Class, Number): Preserve float and double magnitude when converting to BigInteger

[rootvector2]

NumberConverter.toNumber(Class, Number) converts a Float or Double source to BigInteger through BigInteger.valueOf(value.longValue()), so a floating-point magnitude past long range silently saturates instead of keeping its value: converter.convert(BigInteger.class, 1e30d) returns 9223372036854775807 and 1e20f returns the same, not the real magnitude.

the sibling BigDecimal branch just above already formats Float/Double with new BigDecimal(value.toString()) to avoid exactly this, and #401 / #408 established that BigInteger and BigDecimal conversions must preserve magnitude. this routes floating-point sources through new BigDecimal(value.toString()).toBigInteger(); integer sources keep the exact longValue() path and in-range values are unchanged. found while auditing the toNumber narrowing family after #404, which only added the Long and Float range checks and never touched the BigInteger branch.

BigIntegerConverterTest.testLargeFloatingPointMagnitude fails before the change (9223372036854775807) and passes after.

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

Thank you @rootvector2 , merged 🚀