Very cool solution! (But your x and y's are backwards -- but it doesn't matter in the way you're using them).

Maybe I'm missing a nuance in what is expected, but the C++ test_tree_with_23_nodes test (and later) seem broken. Ex for test_tree_with_23_nodes test:
Expected: [ 12, 13, 16, 1, 40, 29, 2, 19, 6, 35, 3, 38, 6, 22, 29, 8, 10, 10, 8, 21, 1, 36, 33 ]
Actual: [ 22, 8, 35, 3, 13, 29, 38, 1, 6, 10, 19, 29, 33, 36, 40, 1, 2, 6, 8, 10, 12, 16, 21 ]

As you can see, the expected starts out incorrectly sorted after the first level

                                     12
                               *13*      16
                           ...

It's been a while, but you're right and your solution is easier to read

Not clear why the invariant checks for n > 0 when i is always at least 1 and it already checks for i <= n...

Although probably never will be hit, assuming the max count of any items is 3 digits (minus a nul terminator) is kinda iffy.

Also, if the string is zero length, it will return an invalid string (i.e. no nul terminator).

How does this return true for the case (" 3 ")?

C tests have test harness warning:

fixture.c:11:52: warning: implicitly declaring library function 'sqrt' with type 'double (double)' [-Wimplicit-function-declaration]
cr_assert_eq(IsCollision(-5, 5, 5.0001, 5, -5, 5*sqrt(5)), true, "Expected true.");
^
fixture.c:11:52: note: include the header <math.h> or explicitly provide a declaration for 'sqrt'
1 warning generated.

looks good!

fixed, thanks!

Something seems off with the C random tests. For example:
< Incorrect Result >

code[13] = {
" uhefkcy mrpdrk uflndjh em zzksswz acry",
"x ogyypkkuvxpxfkajctamdsac uxqk lrsbp f",
"z zwiousp vaozd tygmv wazgstvzx rpbsdnk",
"lixlwoo mam oa ggrzui gtk k rnjcjrjy",
"xvyb gbmlhwcaerzpart dfrjhmlrvinh pvfjz",
"iqvljsba vrsv xl xw njhuq bdllcuuwxwnyw",
"ns ffmvpake q kwnezyhakbq qwxfjplh qvc",
"qfzpnf qabvstbmc bcexzj ucuolr fkov",
"dphohc dqafvqwdpdpowlbd siowt kodkcemb ",
" vepl st hkdi zt gi asvdvq rgvmjjpcuh",
"xmhapp bamj muvhnko uu ywb ynvntvnhdu ",
"eus uwg wmjkz xruttzjgmwy dyjwx ihzvdxa",
"ticc ysrrdcpmhbbzhxpjm uu oqjhikkdkhoa"
}

Submitted: "mmnikmikghmlkkiklklpkiiimjeooolknlikiok"
Expected: "i igh

iiie
i "

Why are you copying the number?

How is calling into the possibly non-trivial function pow() instead of simply writing "diff * diff" a "best practice"?

This approach has zero global ctors (which are a runtime hit).

Ugh. O(n^2) is not a "best practice IMHO.