Preserve fractional bound in BigIntegerValidator range checks

[sahvx655-wq]

The Number-typed minValue and maxValue overrides convert both operands with toBigInteger before comparing, and toBigInteger truncates a non-integer bound towards zero. A fractional bound therefore loses its fractional part before the test, so the verdict is wrong: minValue(BigInteger 5, 5.9) returns true although 5 is below 5.9 (the bound is floored to 5), and maxValue(BigInteger -5, -5.9) returns true although -5 is above -5.9. I noticed this while checking these overloads against BigDecimalValidator, which already compares the same mixed Number bounds exactly, so the two validators disagree on identical inputs.

The fix compares both operands as BigDecimal so a non-integer bound keeps its value. Whole-number bounds and BigIntegers outside the long range are unaffected, and keeping the comparison inside the override mirrors BigDecimalValidator rather than pushing rounding onto callers. Left unfixed, any range check given a Double, Float or BigDecimal bound with a fractional part can admit values just outside the requested range.

[garydgregory]

@sahvx655-wq
Thank you for the PR.
Please see my comment.

[garydgregory]

Hello @sahvx655-wq
You missed the java.math.BigDecimal.valueOf(double) shortcut here.

[sahvx655-wq]

Good catch. I've added a Double branch using BigDecimal.valueOf(((Double) value).doubleValue()) so it matches the toBigInteger helper just below, which already takes that path with the same "no need to roundtrip with a string" note. The fall-through stays on new BigDecimal(value.toString()) for the remaining types (Float keeps its own canonical short form that way rather than picking up the widened double representation).

Pushed in 3b48460 and the range tests still pass.