Report out-of-range NumericDate claims distinctly from non-numeric ones

[arpitjain099]

Fixes #706

What is actually happening

While looking into this I found that in-range scientific notation already decodes correctly. A claim like {"exp": 1.7e9} is parsed by Jackson as a DoubleNode whose canConvertToLong() is true, and getInstantFromSeconds already handles it and returns Instant.ofEpochSecond(1_700_000_000).

The value in the report, 1.733162101e+26, is different: it is about 1.7e26 seconds (a year around 5.5e18), which overflows long and is not representable as a NumericDate or an Instant. So it genuinely cannot be decoded to a date. The defect is that PayloadDeserializer.getInstantFromSeconds reported it as The claim 'exp' contained a non-numeric date value, which is misleading: the value is numeric, it is just out of range.

Fix

Split the two failure modes in getInstantFromSeconds:

• not a number: keep the existing non-numeric date value message.
• numeric but overflows long: a new, accurate message, The claim '<name>' value (<value>) is out of the range representable as a NumericDate.

In-range scientific-notation values continue to decode unchanged. Clamping an absurd overflow value to some wrong year would be worse than a clear rejection, so the out-of-range case is rejected with the precise error.

Tests

Added to PayloadDeserializerTest:

• shouldGetInstantWhenParsingScientificNotationNode: 1.7e9 decodes to Instant.ofEpochSecond(1_700_000_000) (documents that in-range scientific notation works).
• shouldThrowOutOfRangeWhenNumericDateExceedsLong: 1.733162101e+26 raises the new out-of-range message.

The existing non-numeric and normal-integer tests still pass. The directly affected suites (PayloadDeserializerTest, JsonNodeClaimTest, PayloadImplTest, JWTVerifierTest, JWTDecoderTest) run green. I ran these on JDK 11 because the repo's Gradle wrapper (6.9.2) rejects newer JDKs; CI will exercise the full version matrix.

Scope

This is narrower than the title might suggest: scientific notation is already supported for representable values, so this PR fixes the misleading error for out-of-range values and adds the missing test coverage rather than adding a new feature. A separate pre-existing edge (a plain integer that passes canConvertToLong() but still overflows Instant.ofEpochSecond) is orthogonal to this issue and not addressed here.

[tanya732]

Thanks for the contribution, @arpitjain099.

This change correctly distinguishes numeric-but-out-of-range values from genuinely non-numeric ones and provides a more accurate error message. The scope also looks appropriate since it is limited to registered-claim deserialization.

LGTM. Thank you!!