Reject numbers the type cannot faithfully hold

[VSN2015]

Same sweep as #30/#31, applied to the numeric casts. One of these is client-controlled.

The promise

A value the type cannot faithfully represent is a violation, not a guess.

Four ways it wasn't kept

Type	Input	Was
:float	"1e400"	Infinity — overflow, accepted
:float	"1e-400"	0.0 — the entire value lost, accepted
:float / :decimal	Float::NAN, Float::INFINITY	passed straight through
:decimal	"NaN", "Infinity" — literal strings	accepted

The last is the one that matters. BigDecimal("NaN") and BigDecimal("Infinity") succeed where Float() raises, so a client could send the string "NaN" for a :decimal price field and have it stored — a NaN that then breaks every comparison downstream and that no numeric column can hold.

And :float rejected exactly those strings while :decimal accepted them. The two types disagreeing is what marks this as accidental rather than designed.

After

  f   "1.5"            -> 1.5
  f   "1e400"          -> REJECTED
  f   "1e-400"         -> REJECTED
  f   "0e10"           -> 0.0
  f   "0.0"            -> 0.0
  f   NaN              -> REJECTED
  d   "2.50"           -> 0.25e1
  d   "1e400"          -> 0.1e401     ← still fine, see below
  d   "NaN"            -> REJECTED
  d   "Infinity"       -> REJECTED
  d   Infinity         -> REJECTED

Two details worth reviewing

Underflow needs the source text. The result of Float("1e-400") is an ordinary 0.0 — indistinguishable from a real zero after the fact. So a zero result is rejected only when the string named a nonzero significand. Only the significand: the exponent's digits say nothing about the value.

My first attempt scanned the whole string and rejected "0e10" — a genuine zero. The spec caught it; the check now splits on e/E first. That's why "0", "0.0", "0.0000" and "0e10" are all still accepted, and there's a spec for each.

:decimal cannot overflow. BigDecimal has no exponent limit, so "1e400" is a value it genuinely represents and keeps working. Only NaN and Infinity are non-finite there — hence a finite? check rather than a range check.

Verification

• 206 examples, 0 failures (7 new, written before the fix), including the three "still works" cases that guard against over-rejection
• RuboCop clean

[VSN2015]

Review of PR #32: Critical numeric integrity protection. Rejecting non-finite numbers, overflowed infinities, and underflowed zeroes guarantees values can be faithfully stored in database columns.

[VSN2015]

Detecting Float underflow by comparing result.zero? against nonzero_significand?(source) is a clever check to reject inputs like "1e-400" that underflow to 0.0 while preserving legitimate zeroes ("0.0", "0e10").

[VSN2015]

Explicitly checking result.finite? on BigDecimal closes the loophole where strings like "NaN" or "Infinity" were parsed as valid numbers by BigDecimal().