perf(layout): add empty-range fast paths in chunked reader

[caicancai]

This PR short-circuits empty row_range in ChunkedReader across split/pruning/filter/projection paths. It improves boundary-case performance in scenarios where planning/splitting or upstream pruning produces empty work units (e.g. split boundaries, highly selective filters), by avoiding unnecessary chunk iteration, async task setup, and result collection.
Behavior for non-empty ranges is unchanged.

[caicancai]

@joseph-isaacs Excuse me, may I ask if there's anything wrong with this PR, or if I should close it? I haven't seen any comments, so I'm unsure what to do next.

[joseph-isaacs]

Lets me run the benchmarks and we can see.

OOI what workload did you see this being a problem.

[caicancai]

Lets me run the benchmarks and we can see.

OOI what workload did you see this being a problem.

Good question — I didn’t hit a specific production workload regression. This change is mainly a defensive fast-path for valid empty ranges that can appear after split/planning boundaries or highly selective pruning/filtering. The goal is to avoid unnecessary chunk iteration/future setup in those boundary cases and make empty-input behavior explicit across pruning/filter/projection paths. Happy to add a small benchmark/counter if we want to quantify how often this path is hit.

[joseph-isaacs]

Thanks for your contribution