feat: disktable and memtable behave inconsistently when seeking with nonexistent pk

Using the XxxTableTraverseIterator::Seek(const std::string& pk, uint64_t time) will get the next record after this (pk, time). In Memtable, it'll always get the next record. But in Disktable, if disktable does not contain a record with this pk, it will result in a not valid iterator.

**Additional context**
``` cpp
cfo.prefix_extractor.reset(new KeyTsPrefixTransform());
```
Here this extractor is used to get the pk from combineKey(pk, time). RocksDB will use this prefix to improve the searching speed. And using this extractor will cause seek to return not valid if pk is not found.

Look at the XxxTableTraverseIterator::Seek implementation in both Memtable and Disktable. The issue mentions a KeyTsPrefixTransform used with RocksDB. Examine how the prefix extractor affects seek behavior when a primary key is not found. Run existing tests for table iteration to see the inconsistency, and ensure both table types return a valid iterator pointing to the next record.

Vom Indexierungsmodell aus dem Issue-Text verfasst.