Handle non-finite bounds in BigIntegerValidator range checks

[sahvx655-wq]

BigIntegerValidator's minValue(Number, Number) and maxValue(Number, Number) compare the operands as BigDecimal, but unlike the equivalent BigDecimalValidator overloads they never guard for a non-finite bound. A Double.NaN, POSITIVE_INFINITY or NEGATIVE_INFINITY argument is routed straight into BigDecimal.valueOf(double), which cannot represent those values and throws NumberFormatException, so the call (and the inherited isInRange that delegates to it) blows up with an undeclared exception rather than returning a boolean. I traced this from an open-ended range check where an infinite upper bound threw instead of accepting every finite value; BigDecimalValidator accepts the same bound without complaint, so the two validators disagree.

The fix guards both overrides with isFinite and falls back to the doubleValue() comparison when either operand is non-finite, mirroring BigDecimalValidator. The finite path is untouched, so the exact-magnitude and fractional-bound behaviour stays as it was; only the previously-throwing case changes, with a NaN bound never satisfied and an infinity treated as an open bound. Keeping the guard in the callee means every entry point stays consistent without callers having to sanitise their bounds first.

[garydgregory]

Please keep track of what is happening to your existing PRs: #410 has been broken for almost a week.

[garydgregory]

Hello @sahvx655-wq
Thank you for the PR.
I think the new test should also check non-finite values against each other and themselves.
TY!

[sahvx655-wq]

Good point. I've extended testNumberRangeNonFiniteBound to exercise non-finite operands on both sides: each infinity against itself, the two infinities against each other, and NaN against NaN. Since the non-finite path falls back to the doubleValue() comparison, an infinity equals itself and orders correctly against the other infinity, while anything involving NaN comes back false, which is what those new assertions pin down.

On #410, that's since been merged, so it should be sorted now. I'll keep a closer eye on the state of the open ones.