I think it is perfectly ok to use our current calendar (the Gregorian)

Technically speaking, it is Proleptic Gregorian calendar, not Gregorian calendar. Proleptic Gregorian calendar extends the range to 1 CE.

The problem here is, most datetime libraries implicitly implements Proleptic Gregorian calendar for their Gregorian calendar because of reasons, which is technically not correct: a very pedantic datetime library can bark at this practice, and they'd be perfect justified to do so. So it's not advised to touch the range that's only valid in a Proleptic Gregorian calendar.

On the other hand the Gregorian calendar as implemented in PHP has a valid range from 4714 BCE to 9999 CE

Well, this is abnormal even in the sense of Proleptic Gregorian calendar.

(Also, the input range should really be specified.)

What about translations to languages other than php? should they use the same range as php version, even if it is not supported out of the box? or should use whatever they support?

Limitimg the range to just valid Gregorian calendar years it the easiest way to make the kata translatable. For example the "Leap years" kata uses range 1600-4000 in all languages.

You do have a point about the Gregorian calendar not being invented until 1582 and many palces did not adopt the use of it until much later. On the other hand the Gregorian calendar as implemented in PHP has a valid range from 4714 BCE to 9999 CE. I think it is perfectly ok to use our current calendar (the Gregorian) to find days and dates in both history and future, and from that perspective the calculated Sundays would be correct.

Input range in random tests is 1-4000, but month, week and day of week are calendar concepts, Gregorian calendar starts from late 1582, and the tests does not use the proper calendar functions in PHP for its calculation (date is a timestamp function; at best you can only say it's Julian Day). So whatever calculated is wrong/invalid in some of the input range.

Your explanation makes sense, but it is fairly easy to spot the mistake when writing or changing the tests. If all 'noice' is removed the test is trying to assert that 0 is the same as 0.0:
$this->assertSame([0], moveZeroes([0.0]));

As you say, at this moment all zeroes must be converted to integer 0 or the tests with non integer zeroes will fail. It does add some interesting complexity to the kata that you have to find different kinds of zeroes and move them, but it is also not clear in the instructions if you have to keep the order of your zeroes when moving them to the end.

I think it was tested with a weak comparison assertEquals, but as of right now changed (don't know when?) to a stricter one assertSame, and change only the method not the expected value (making some user solutions invalid).
Because of that, I guess we can assume that all zeroes value (wether integer or double) needs to be converted to integer 0 ?

In PHP the second test includes 0.0 in its values:
$this->assertSame([9,9,1,2,1,1,3,1,9,9,0,0,0,0,0,0,0,0,0,0], moveZeros([9,0.0,0,9,1,2,0,1,0,1,0.0,3,0,1,9,0,0,0,0,9]));

the digit 0.0 are counted as a zero but expected to be a single zero after moving to the end. All tests will pass if a single 0 is added to the end for any digit that evaluats as 0 (including 0.0).