Do not cast floats past the int range, or NAN, where PHP does not - #6541

Three places cast a float to int or to string where PHP does not do that. Each gave a wrong result, and PHP 8.5 now also warns about the cast. They share a root cause: PHP_INT_MAX is not representable as a float, so (float) PHP_INT_MAX (2^63) is already past the int range.

• NAN == 'NAN' was inferred as true (and reported as "always true"). LooseComparisonHelper compared a number with a non-numeric string through the number's string cast, but PHP never stringifies NAN: NAN is equal to nothing. It is false now.
• int<PHP_INT_MIN, -1> / -1 was inferred as float, losing every value the division produces as an int. integerRangeMath() cast the overflowing bound (PHP_INT_MIN / -1 is the float 2^63) to int, which wrapped it around to PHP_INT_MIN and left the range empty. The bound now stays at the edge of the int range, since the values past it are floats: the result is int<1, 9223372036854775807>.
• IntegerRangeType::createAllSmallerThan((float) PHP_INT_MAX) returned *NEVER* instead of int, and createAllGreaterThanOrEqualTo() had the same boundary. Their guards compared with >, which lets 2^63 through to a cast that wraps it. PHPStan's analysis of its own code reached this once the division above stopped producing an empty range.

InitializerExprTypeResolver and IntegerRangeType are turbo-shadowed, so their C++ mirrors get the same changes, followed by the expected-version bump.

Found through the PHP 8.5 warnings the turbo smoke test's type-family.php child prints to stderr (the warnings that deadlocked the Windows 8.5/8.6 legs before fa79f34). The remaining "Undefined array key 1" from TemplateArgumentResolver is that test deliberately passing a gapped array, not a bug.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NBzALCg92yf3LXFxxNBzoY