Clarifying key ordering in etcd range requests

Problem

Range behavior depends on ordering and limits, so the filtering code and tests need to make those rules easy to follow. The existing tests did not cover key-ascending results with a limit as clearly as they could.

Changes

I rewrote the range-result filter with explicit conditionals, added key-ascending and limit cases to the KV range tests, and optimized a range request using key-ascending sorting.

Result

The filtering logic is easier to read, the tests cover the ordering and limit combination directly, and the range path can use the requested key order.

Commits: filter refactor, range tests, range optimization