[Improve] benchmark ordered range scans and identify fan-out bottlenecks #3158

Context

Follow-up to #3140. That PR establishes correctness for ordered HStore range-index scans through Store-local and client-side K-way merge. This issue is limited to measuring the performance characteristics and deciding which optimization, if any, is justified.

Benchmark scope

Build a reproducible benchmark matrix covering:

• Small limits with many partitions
• Medium limits with sparse matches
• Large limits and page/cursor continuation
• 1, 4, 16, and 64 partitions
• Warm and cold cache, plus representative network latency

Record time to first result, total query time, RPC/open-stream count, transferred bytes, client heap usage, and Store CPU.

Decisions after the baseline

Use the results to decide whether to open focused implementation issues for:

1. Partition pruning, when range metadata can safely eliminate non-overlapping partitions.
2. Client-driven initial and subsequent page-demand sizing, when it reduces unused data materially.
3. Prefetch/pipelining, after characterizing existing gRPC streaming and buffering behavior.

Store-local merge pushdown is already delivered by #3140 and is not duplicated here.

Acceptance criteria

• Benchmark configuration and results are reproducible.
• The bottleneck and recommended next optimization are documented.
• Further implementation work is split into focused issues only when supported by the measurements.

I will follow up on this issue.