fix: prevent silent wraparound in out-of-range numeric conversions

[AdamMagued]

Summary

Fixes #356

When converting typed numeric inputs (such as uint64(math.MaxUint64) or float64(1e300)), toNumber[T] directly executed unchecked Go conversions T(s) without verifying if the value fits the target representation. As a result:

• Out-of-range unsigned integers wrapped to negative signed integers (e.g., ToInt64E(uint64(math.MaxUint64)) == -1, nil).
• Out-of-range floats or NaN values converted to math.MinInt64 or wrapped with nil error due to implementation-defined float-to-int conversion behavior.
• In contrast, equivalent values passed as strings through strconv were rejected with range errors.

Changes

• Added range-fitting checks to toNumber and toUnsignedNumber before performing type conversions.
• Implemented numberFitsFromInt64, numberFitsFromUint64, and numberFitsFromFloat64 helpers:
  • Validates value ranges for integer targets (including architecture-dependent int/uint sizes via strconv.IntSize).
  • Guards float-to-integer conversions against NaN, ±Inf, and overflow (f >= float64(1<<63) or f < float64(math.MinInt64) for int64).
  • Preserves integer truncation semantics for floats within representable bounds (e.g., -128.9 to -128).
  • Unconditionally permits integer/float conversions to float targets.
• Added regression tests in cast_test.go covering out-of-range conversions for integers, floats, NaN, and ±Inf.

Verification

• Run go test -v ./...: 100% passed.
• Run go vet ./...: clean.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[AdamMagued]

Closing in favor of earlier community PR #357 to avoid duplicate review effort.