Fix reverse secondary-index scans over an inverted range

[heifner]

A reverse get_table_rows on a secondary index with upper_bound below lower_bound started its scan below its own stopping point. When the queried table's partition comes first in the chain's secondary index (true of whichever contract account sorts lowest), the scan's first step decremented the index's begin(). That is undefined behavior any API caller could trigger:

clio get table 1secrev users --index byowner -r -L '{"byowner":"u4"}' -U '{"byowner":"u1"}'

The response already came back empty in our builds, so callers see no change. The scan now starts at the lower bound's position when the range is inverted, so the page is empty by construction, as it already was forward and on the primary index.

get_kv_rows_inverted_range_test checks an inverted range on both indexes in both directions. The contract is deployed to 1secrev so that its secondary partition comes first in the index, and the reverse scan lands on the index's first entry. The test also passes against the old code, because the stray read happened to come back empty. With a temporary assertion on the decrement, the test tripped it on the old code, and the assertion stayed silent with the fix.

[huangminghuang]

Reviewed the diff and surrounding index and bounds-handling code at f7b5123. No actionable findings. Validation was source-based; I did not run the PR tests locally.