- I added expanding deep branches into every add, in an accumulating way equivalent to recursion. this keeps the tree depth within new bounds when the leaf count drops, and now some branches are merging, covering that code

- I made the test a little more pathological by shortening the random writes so they sparsely cover old data more, which widens the tree and slows execution. thinking on addressing this.

I started copying the code to C a tiny bit, just a start, not attached.

thinking on handling pathological writes just a little

- maybe ensuring there are not internodes with single children so more leaves are clustered?

- maybe copying leaves up rather than internodes, as investment in future use when the flush is deeper?

- considering what property relates to the slowdown: number of nodes traversed? what about in languages with different properties?

- considering bounds on things: in a worst-case scenario with an ideal tree, how many new nodes should be attached to a new root, at most

might make sense for me to just make some code that uses it, given some of the ambiguity here.