write out the last index of the serialization memory and pass it to the tree deserializer (which uses it in a slightly buggy way, which we should fix)

added stochastic test to ensure that the tree-equality check is working correctly; and apparently it can return equality when none exists, this is a bug we need to fix

add a quick-and-dirty special-casing for handling the start symbol in the derivation tree to avoid it spuriously appearing twice

limit how far we look into the serialized parse tree memory (in preparation for adding the "last address written" CSR/output to the gateware itself)

Gprim has effects and we must respect this by scheduling the addition of X_ijk to the derivation tree *before* invoking Gprim! This fixes the order bug!

we are generating almost-correct trees. two issues remain: how to handle the starting term (rn our approach causes a weird duplicate) and also understand why we are getting anomalously permuted order within a level of the tree

convert tokens to name (with an awful ad-hoc scheme that we should revise later) to demonstrate end-to-end parse correctness

prepared instrumentation for tracing the mutual recursions to investigate this bug (which looks suspiciously like a highly elaborate off-by-one)