KV Store 续：评论区补充的测试用例，比我正文想得还细

上次发了 KV Store 的多阶段练法，没想到评论区补充的东西比正文还实在，尤其 dan_chun 给的几个测试思路，我自己练的时候真没想这么细。先整理出来发一版，主要想听听大家的意见，我肯定还有漏的。
版本化存储最容易翻车的是 delete，他给的用例是这样的：
t=1 put 一个值
t=2 delete
查 t=3，应该是空的
再查 t=1，还得能读到老值
就这一条，版本查询和墓碑（tombstone）有没有做对，一测就知道。我之前只测了删除之后查不到，没测删除之前的时间点还能不能查，等于一半逻辑是裸奔的，现在想想挺后怕的。
他还补了一个思路，我看完有点服气：别光手写用例，写一个最笨的参考实现，就是 dict 加全量扫描那种，逻辑简单到不可能写错，然后拿随机操作序列去喂两个实现，结果对不上就说明快的那个有 bug。他提了 Hypothesis 这个库，我去翻了下，好像就是干这个的，不过我还没上手用过，用过的朋友说说靠谱吗。
顺着这个思路我自己又凑了几个自测点，不一定对：
delete 之后隔一段时间再 put 同一个 key，两个时间段分别查，别串了
事务里改完又 rollback，外面查不能看见中间状态
同一个时间戳又 put 又 delete，顺序怎么算，这个我到现在也没想清楚
我练到后面越来越虚，感觉用例没想全的话，写得再快也白搭，不知道是不是就我这样。上面这些有想错的、或者还有什么必测的坑没列到的，麻烦直接指出来，我改。后面整理出新的一版再更新上来。

同一时间戳可以先把约定写进题目：如果允许多次写入，就用 (timestamp, seq) 排序，seq 由提交顺序分配，get(k, t) 取 timestamp ≤ t 的最后一条记录，遇到墓碑就返回空。可以做一对镜像测试：同一 t 下 put→delete 应该为空，delete→put 应该读到新值；两组再查 t 之前，都应读到旧值。参考实现直接按这个规则全量扫描，随机测试时刻意把时间戳限制在几个值里，更容易撞出排序和二分边界问题。