[citizen-stig]

During the merkle update, every key's seek ends with a beatree fetch of the terminal leaf's key and value hash. For a key the caller read and passed to Session::finish as Read(Some(v)) or ReadThenWrite(Some(v), _), that data is already known: if the terminal leaf is hash_leaf(key, hash(v)), it is this key's own leaf. This PR resolves it without I/O in that case.

Changes

• merkle::KeyReadWrite::Read and ReadThenWrite now carry the hash of the read value. nomt::KeyReadWrite::to_compact computes it next to the written value hash. The actuals are not modified, so the rollback delta still sees the read values, whether or not it is finalized before compaction.
• Seeker::push takes an optional known_value_hash. The merkle range workers pass the read value hash. Warm-up and prove pass None.
• When a seek reaches a leaf node, RequestState::resolve_leaf compares H::hash_leaf(LeafData { key, known_value_hash }) with the node. If they match, the request completes with that leaf data. Otherwise, or with no known value, it falls back to the existing begin_leaf_fetch.

The public API doesn't change. A matching leaf hash commits to exactly the key and value hash that a fetch would return, so the seek result (and the witness) is the same. A key that was absent, or a read value that doesn't match the trie, falls back to the normal fetch.

Trade-off: read values are now hashed in Session::finish on the calling thread, which used to hash only written values. #951 spreads that hashing across threads.

Performance impact

TODO: to be filled in after benchmarking.

[citizen-stig]

breaking API and concern for ZK security