Perhaps nan/inf protection should be more comprehensive

a87d53bdf0c563334fa91eeb7d9624a6fdf1598c added nan/inf protection to `luaL_checknumber` and `lua_tofloat`.

* what about `lua_tonumber`? It also produces floats and [seems to be used a lot](https://github.com/search?q=repo%3Abeyond-all-reason%2Fspring%20lua_tonumber&type=code) but didn't get protection.
* should functions that produce an int also get protection? In Lua, the `number` type is a float and the engine does a cast when it wants an int. Isn't this UB if the float was nan/inf? Can it be UB or implementation defined if the float was outside int bounds? This one is less about crashes (since all ints are "valid") and more about desync. I assume it's handled by all of our usual SSE/streflop/etc magic that prevents all the other ways floats could desync but perhaps it's worth checking either way.

Start with commit a87d53bdf0c563334fa91eeb7d9624a6fdf1598c and inspect the existing protection in luaL_checknumber and lua_tofloat. Trace lua_tonumber and the engine paths that cast Lua numbers to integers, then check the relevant C++ behavior for NaN, infinity, and out-of-range values. Done means determining whether additional protection is required and documenting the desync or undefined-behavior implications.

Written by the indexing model from the issue text.