fix overflow in the integer to floating point safe-cast checks

[aysha-afrah26]

The integer to floating point branches of the two safe-cast helpers hit undefined behavior at the 64-bit extremes, the opposite direction from the float to integer boundary fixed in #1162. checkTruncation (convert_impl.hpp), behind Any::cast<double>, computes std::abs(static_cast<int64_t>(from)), which overflows for INT64_MIN, so a Debug or UBSan build lets INT64_MIN through the 2^53 precision check while an -O2 build rejects it. ValidCast (safe_any.hpp), behind Blackboard::set on an entry locked to double or float, rounds the integer to the floating type and casts it back, but INT64_MAX and UINT64_MAX round up to 2^63 and 2^64, so the cast back is out of range. I noticed it with UBSan: restoring {"x": -9223372036854775808} through ImportBlackboardFromJSON and ticking a Script with r := x < 0 reports the abs overflow and the node returns SUCCESS, while a Release build of the same tree throws the "Loss of precision" error. The fix computes the magnitude in unsigned arithmetic, and in ValidCast returns false when the rounded value is at or above 2^digits of the source type, before casting back, so both extremes are rejected the same way in every build. The new BasicTypes.IntToDoubleBoundary test fails under the repo's UBSan configuration before the change and passes after (full ctest 539/539 with UBSan); the change is header-inline with no API or ABI impact.