feat: experiment with a shared Parquet read-ahead queue

[peterxcli]

Which issue does this PR close?

Related to apache#24393. Experimental stage 4 of the Parquet I/O stack, based on #7.

Stack, with each PR targeting its predecessor: #4 → #5 → #7 → #8 → #9.

Rationale for this change

One future row group per stream can still leave workers waiting for another file's metadata and initial data. Prepare a bounded queue of future file-range jobs that reorderable sibling streams can claim.

What changes are included in this PR?

Add an opt-in shared queue using the existing morsel planners, with fixed job/byte caps, query-pool reservations, initial Parquet payload reads, and demand fallback when admission fails. Retain cancellation and error handling. The adaptive memory heuristic is isolated in the next PR.

What is the testing strategy for this PR?

Cover ready-work selection, cancellation, hard budget limits, memory release, filtered groups, and demand fallback. Compare this stage with its parent over the full partitioned ClickBench dataset on lsa-cupid1, including warm/cold files and latency controls.

Workspace Clippy with all targets/features, the extended test suite, and the focused Parquet/queue checks passed on lsa-cupid1. Tests use a private PID namespace, CPUs 96–111, and a 65,536 file limit.

Full partitioned ClickBench on lsa-cupid1, /work/peterxcli NVMe: 100 files, 99,997,497 rows, all 43 queries, eight workers/partitions. Versus the immediate parent, the sum of query medians changes +0.21% / +0.76% warm and -0.26% with evicted files (negative is faster). Warm values are two reversed-order passes; evicted files use three runs per query.

Keep experimental: eight queries are over 5% slower in both warm passes. Q21/Q29 with 8 ms added per read improve 20.00% / 5.10%, but this control does not establish actual object-store performance. Results and methodology · 43 per-query comparisons and CPU charts. Result-ordering limitations and synthetic-latency controls are documented in the report.

Are there any user-facing changes?

An execution-local with_scan_read_ahead API enables the experiment for reorderable streams with upfront I/O. It is disabled by default and not serialized. Minimum per-job accounting can prevent larger initial payloads from fitting; warm-query overhead remains an explicit review question.