Describe the bug

MdbxStorageCursor / MdbxTrieCursor iteration depends on an explicit seek() call.

Given dup-sorted data:

• (hashed_address=0x01, slot=0x11)
• (hashed_address=0x02, slot=0x12)

If a cursor is constructed for hashed_address=0x02 and iteration starts with next(), it returns None (no rows).
But if seek(hashed_address) is called first, then next() returns the expected row.

Expected: cursor constructed for a key should return the first row for that key on next() without requiring a manual seek().
Actual: next() yields nothing unless seek() was called, and this only shows up when the key is not the first key in the table.

This breaks consumers that assume “cursor-for-key is ready to iterate” semantics.

Steps to reproduce

Described above

Node logs

Platform(s)

No response

Container Type

Not running in a container

What version/commit are you on?

unstable

What database version are you on?

Which chain / network are you on?

What type of node are you running?

Archive (default)

What prune config do you use, if any?

No response

If you've built Reth from source, provide the full command you used

No response

Code of Conduct

• I agree to follow the Code of Conduct