Since we're keeping the next key on each call, could we optimize this?  In other words, if we got a key from the store last call, call next/prev on the store first.  We already have the next key from the cache from the last time through, so we can check whether the one we get from the cache is larger/smaller.

This would turn this code into more of a traditional merge of the two sorted stores, with half as many calls to kvs_next/prev.  The tradeoff is additional complexity to track whether we're getting repeated calls to cursor next/prev.