Reject underscore separators and whitespace in numeric coercion

[VSN2015]

The bug

Numeric scalar casts (:integer/:float/:decimal) delegate straight to Kernel#Integer/Float/BigDecimal, which silently accept underscore digit separators and surrounding whitespace — a convenience meant for a number literal in Ruby source code, not for a value arriving in a request body. This contradicts the module's documented "deliberately strict" coercion philosophy, and is the same class of leniency Coercion already deliberately hardens against for NaN/Infinity and bare-significand 0e10 forms — just slipping through a different door:

Permittable::Coercion.cast(:integer, "1_8")    # => [:ok, 18]      (should be rejected)
Permittable::Coercion.cast(:integer, " 99 ")   # => [:ok, 99]      (should be rejected)
Permittable::Coercion.cast(:float, "1_8.5")    # => [:ok, 18.5]    (should be rejected)

"1_8" is not how a client spells eighteen, and " 99 " is not how one spells ninety-nine; a client sending either is more likely to have a formatting bug upstream than to mean the number that results.

The fix

Before delegating to Integer()/Float()/BigDecimal(), the String branch of each numeric cast (cast_integer, cast_float, cast_decimal) is now checked against a strict canonical numeric format — an optional sign, digits, an optional .digits, and an optional exponent, with no underscores and no surrounding whitespace:

INTEGER_FORMAT = /\A[+-]?\d+\z/
NUMERIC_FORMAT = /\A[+-]?(?:\d+(?:\.\d+)?|\.\d+)(?:[eE][+-]?\d+)?\z/

A String that doesn't match reports the same "invalid_type" violation the module's other strictness checks already use, rejected before it ever reaches Integer/Float/BigDecimal. Legitimately valid numeric strings keep working exactly as before — plain integers, leading-zero integers ("01"), decimals, negative numbers, and valid exponent notation like "1.5e10" or the large exponents :decimal genuinely represents ("1e400") — since none of those forms use underscores or whitespace. :decimal's existing NaN/Infinity string rejection is unaffected: those literals don't match the numeric format either, so they're still rejected with "invalid_type", just at the format-check gate instead of via BigDecimal's own NaN/Infinity parsing.

Verification

• New tests written first (spec/permittable_spec.rb), confirmed to fail before the implementation change and pass after
• bundle exec rspec — 853 examples, 0 failures
• bundle exec rubocop lib/permittable.rb spec/permittable_spec.rb — no offenses

🤖 Generated with Claude Code