Oh, nice catch! My bad. Thanks for the fix.

Oh! Okay. (:

Thank you for your attention.

Oh! That is because I simply translated this kata directly from the js version without giving it much thought. That version performs 20 random tests in the range (1, 40). It probably has something to do with integer limits.

Given the limits of native integers in C#, I took the liberty of tuning the random tests up to the larger range (1, 68) with 30 tests. Sounds better?

Since js can only safely represent integers (natively) in the range (-2^53, 2^53), the last row it can compute without resorting to bignums is the 57th, whose largest element is ~7.6e15, while 2^53 is ~9e15. The maximum in the 58th row is ~1.5e16.

C#'s largest native integer is a 64-bit one. The signed flavor goes up to 2^63-1 (about 9.2e18), which lets us represent elements up to the 67th row (maximum about 7.2e18), whereas the 68th row's maximum is about 1.4e19. Since the unsigned version goes up to 2^64-1 (about 1.8e19), it does not make a difference; and 67th row is the farthest one can do in C# without resorting to some extra work.

(Hm, now that I think about it, we could also test how the program performs in the entire range instead. It finishes in 2300ms, just tried it. What do you think?)

C# translation available for review.

Beautiful, clear, efficient solution.
Love the way you avoided writing small loops using Linq and string manipulation: you achieve code readability without losing efficiency.
The only for loop remaining was unavoidable, and yet the code remains very clean. Congrats.