RocksDB iterators silently skip corrupted entries instead of reporting errors

[huitseeker]

The RocksDbDirectLeafIterator and subtree iterator use find_map with .ok()? to discard deserialization errors, causing corrupted database entries to be silently skipped. Callers receive incomplete data without realizing corruption occurred, which can hide storage problems and lead to incorrect rebuilds or partial audits.

The root cause is error swallowing in the iterator implementation. At miden-crypto/src/merkle/smt/large/storage/rocksdb.rs:1001-1007, the leaf iterator does:

self.iter.find_map(|result| {
    let (key_bytes, value_bytes) = result.ok()?;  // RocksDB error discarded
    let leaf_idx = index_from_key_bytes(&key_bytes).ok()?;  // Decode error discarded
    let leaf = SmtLeaf::read_from_bytes_with_budget(&value_bytes, value_bytes.len()).ok()?;  // Deserialization error discarded
    Some((leaf_idx, leaf))
})

The subtree iterator has the same pattern at lines 1049-1056. Any error at any step causes that entry to be skipped silently, and iteration continues as if the entry never existed.

To fix this, add a strict iteration mode that returns Result and surfaces the first error encountered, or accumulate a warning counter that callers can check to detect data loss. This prevents corrupted entries from being ignored silently.

[bobbinth]

With #1499, the RocksDB backend will move into miden-node. So, this issue may be more appropriate there.

[huitseeker]

This should move to 0xMiden/node. The copied RocksDB backend in PR #1499 keeps the same iterator pattern that skips bad entries by using with , so the bug lives there now.