Restricting inputs to integers is silly. Accept floating point inputs. You have to deal with floating point numbers anyway.

Rounding is not the correct solution for floating point representation inaccuracy. Testing with a margin for error is.

See Docs -> Authoring -> Recipes -> Working with Floating-Point Numbers.

Was the other kata retired for being a bad implementation or for not being novel?

Restricting things has already been invented, so reinventing that wheel ( but even more square ) is not very useful. It apparently just can't be done right. This is documented in the docs.

Hardcoding the answers can be fixed by not restricting the domain to integers, and interpolating the results can be fixed by requring full precision ( rounding is not the correct solution anyway ).

The real problem is kata are tested for results, not methods; problems like these are simply not well-suited to them. Whenever there is a native function for something, that should be the solution to the kata.

The issue here is not that people can still use the built-in functions in your kata (and the solution to that is "write the kata in a language that doesn't provide the built-in"). The actual issue is that the kata is really not novel, being a duplicate that has been retired.

Is there any better way to prevent cheating the kata?

Such katas are worthless and it will eventually end up like this one due to 1, 2 and 3

Oops...okay, I've disabled "require" now as well lol, thanks for bringing this to my attention!