That's something I didn't know, thanks! It's fixed now :)

white space is a typo of whitespace and doesn't mean what you use it for.

that character's name is space.

tagging as issue because it's misleading in a way that isn't relevant to the task (as opposed to clever phrasing), lowers the quality of the problem, and will teach beginners something that is wrong.

please remove all occurrences of "white" from the description and tests.

.

The examples should be an image or ascii/unicode visualisation instead, so that the solver does not need to wonder whether it contains hidden information in its text, and to make it easier to parse in general.

All the rest of the instructions below the rules table should be replaced with an explanation of what part of the data to return, that current text is difficult to read and says nothing.

The wikipedia mention should instead be a hyperlink for the first two words "Rule 30" so as to not make the solver question whether there is required information there that the instructions leave out. Also improves signal-to-noise ratio.

What, leetcode doesn't tell you when your code is wrong?

and the words in the result should be lowercased

Are you looking at what the input was? Otherwise you can't state that you've reversed them, not knowing the original order.
You're free to print out information about what's going on in your code. You can print out things like what the input to your method was, and what value your method returns. That way you can manually judge whether your method does what it's supposed to, and whether that agrees with the error report that you're getting.

It also doesn't matter whether the input is a reversed English word, or a word at all. The input can therefore never be "reversed to begin with" as nothing is supposed to be in any particular order in the input.

limiting the queue size to 500 is arbitrary and suspicious. I ran your code to see if it hit that limit, it does. there's no way that's a correct thing to do.
(either the limit isn't needed, and then it's irrelevant to limit it, or, it is needed, but then that wouldn't be a correct way to handle it)

You are probably misinterpreting your output, for example by mutating the input value so that it's no longer what you got or by looking at the input of one case and the expected output of another.

0 could be a good idea for the beauty of solutions.

"Having a failure share representation with success can lead to failures accidentally being treated as success."
If you can treat negative length of the side as a success it means you didn't understand the task. You can't have a piece of stick of a negative length.

"If not knowing about the possible None, that is still better than not knowing about the possible -1, being forced to deal with it is the whole point."
None can be an indicaion that there occured some case that your code didn't take care of. I still opt for -1 as an indication of no square case.

"s/brake/break"
I didn't understand it. Where is it? How did you come across it?

Having a failure share representation with success can lead to failures accidentally being treated as success. By making them different you make it difficult or impossible to mix them up.

If not knowing about the possible None, that is still better than not knowing about the possible -1, being forced to deal with it is the whole point.

If 0 can be considered a success then keeping it as int makes sense. A square having a side of -1 would be something very different though.

If the sentiment is that you don't like mixing types, then I would still consider int|NoneType to be a single type, a union of two others. Exceptions are another way to represent that, again keeping failure and success separate.

(It still says brake btw)

I would like the output to remain integer.

Both 0 and -1 make equal sense to me, both indicate that there can be no square constructed.

Or just 0 (would make sense)...

s/brake/break

consider None over -1