Reported the same problem yesterday. But I say it again simple additional test case will do, e.g.:
Assert.AreEqual(20000000001, Kata.NextBiggerNumber(12000000000));
good solutions pass it in milliseconds and brute force will always time out.

The test uses equal comparations on floating points (this is bad, very bad practise!). We have to round it to 6 digits using floor().
This is still bad, because the results could be in the form 1.24499999999564, while answer is 1.245. The numbers are close enought, but by comparing truncated number we get wrong answer.
If no one want to repair this one, just remember to compare floating points in proper way next time:)

next_permutation will never be not performant enough. But you can ban using next_permutation, prev_permutation and the # character (and compensate for the lack of # by including potentially useful headers like string and vector and probably even algorithm in preloaded). I can't immediately think of a way to bypass it; if there is some then it would be at least not too obvious.
UPD And ban %: too.
UPD Actually, it's still possible to use preprocessor even after this. So unstead of # and %: it's better to ban include and define.
UPD It should work with either banning # and %: or include and efine but in either case possible line continuations inside tokens should be considered.

Can you make it so that the number and the scope of the random tests would make using std::next_permutation not performant enough?

In case, go for it!

The table here: https://github.com/Codewars/codewars.com/wiki/Kata-Beta-Process links number of required votes and satisfaction. In mentions 'votes', so probably all 'satisfaction' votes counts.
CW documentatin is a mess, two versions, neithier of them explains what to do :/

Hi. What is wrong with this translation? It sits in queue for 7 month now.