Compare float bounds against PHP_INT_MAX + 1.0 in IntegerRangeType

[zonuexe]

#6541 (53cc365) changed IntegerRangeType::createAllSmallerThan() and createAllGreaterThanOrEqualTo() to treat a float bound >= PHP_INT_MAX as past the int range. On 64-bit builds that is right, because comparing with PHP_INT_MAX converts it to float and rounds it up to 2^63. On 32-bit builds PHP_INT_MAX (2147483647) is exact as a float, so:

• createAllGreaterThanOrEqualTo(2147483647.0) returns *NEVER*, although the int PHP_INT_MAX satisfies $i >= 2147483647.0. This is unsound.
• createAllSmallerThan(2147483647.0) returns int instead of int<min, 2147483646>. This is sound but imprecise.

This PR decides on the ceil() that is about to be cast, and compares it with PHP_INT_MAX + 1.0. That is the first float above PHP_INT_MAX and is exact on both widths (2^63 and 2^31). Using the ceil() rather than $value matters on 32-bit, where for example 2147483647.5 lies between PHP_INT_MAX and PHP_INT_MAX + 1.0. The turbo mirror in turbo-ext/src/IntegerRangeType.cpp gets the same change, followed by the usual bump commit.

64-bit behaviour is unchanged for int|float input. On 64-bit, every float at or above 2^52 is already integral, so ceil($value) >= 2^63 is the same test as $value >= (float) PHP_INT_MAX. The only observable difference is for out-of-contract arguments (a string or bool passed to @param int|float $value). createAllSmallerThan() now reaches ceil() first and throws its TypeError for these, even where the old loose comparison returned a type. The native side does the same, and type-family.php records it.

IntegerRangeTypeTest replaces the 64-bit-only expectations from 53cc365 with a data provider that branches on PHP_INT_SIZE. On 64-bit hosts it passes both before and after this change, so on 64-bit CI it only guards against regressions. I ran it on linux/386 (Docker php:8.5-cli, PHP 8.5.10, PHP_INT_SIZE 4). Before the change, two rows fail there: createAllGreaterThanOrEqualTo(2147483647.0) gives *NEVER* instead of 2147483647, and createAllSmallerThan(2147483647.0) gives int instead of int<min, 2147483646>. After the change all 18 rows pass.

Whether PHPStan supports running on a 32-bit PHP at all isn't settled (phpstan/phpstan#11711, phpstan/phpstan#14948), and composer.json has no php-64bit requirement. This PR only makes these two factories correct on such a host and keeps 64-bit behaviour as it is. If 32-bit analyser hosts should be unsupported instead, feel free to close this.

#6542 applies the same >= guard to 2.2.x; I'll update it to this approach so the two branches agree when 2.2.x is merged up.

Verified on macOS arm64, PHP 8.5.10:

• Strict turbo build, smoke.php (ALL OK), side-by-side.php, signature-parity.php, walk-trace.php --shards=8 (identical)
• Full test suite with and without the extension
• Self-analysis output byte-identical with and without the extension