Disk polling: measure owner completion service under concurrent polling

Part of #4174, which records the shared benchmark setup and evaluation criteria.

Measure whether admission or owner service limits disk polling under concurrent load. [The owner pump](https://github.com/apache/iggy/blob/8f1c0e260076f9fbe49539e904e43895bc24c3fe/core/shard/src/router.rs) services one completion after ordinary work and also has a completion select arm. [Capacity is reserved before I/O](https://github.com/apache/iggy/blob/8f1c0e260076f9fbe49539e904e43895bc24c3fe/core/shard/src/poll/completion.rs) and held until dequeue or discard.

The [limit](https://github.com/apache/iggy/blob/8f1c0e260076f9fbe49539e904e43895bc24c3fe/core/configs/src/server_config/sharding.rs) counts running reads plus queued completions, including reads continuing after requester timeout. It bounds operations, not retained bytes or time spent waiting behind owner work.

An earlier diagnostic used base `0d862e36dcc42fd1fffca2f4504886718bf7757f` plus an instrumented port of the archived lane, rather than the current implementation. At capacity 1024:

| Observation | Without writes | With writes |
| --- | ---: | ---: |
| Maximum ordinary inbox occupancy sampled at pump starts | 1 | 2 |
| Maximum candidate reservation occupancy | 1 | 1 |
| Maximum candidate completion queue occupancy | 1 | 1 |
| Rejected candidate reservations | 0 | 0 |

This separate diagnostic comprised eight captures of 10,000 explicit offset polls, using the shared sequential consumer workload described in #4174. Its report and captures remain archived locally. Pump samples can miss brief peaks; these observations establish neither saturation nor a benefit from greater capacity. Instrumented timings are not a clean performance comparison.

1. Reuse the parent's stage capture. If owner service appears material or a representative concurrency requirement warrants it, run a short ramp with several simultaneous reads and ordinary work.
2. Record offered and completed load, active reads, reserved capacity, queue occupancy, admission rejections, retained bytes, write progress and tick delay.
3. Separate enqueue to owner acceptance from acceptance to caller resumption. Correlate waits with actual owner work and service intervals, sharing timestamps with #4178.
4. If a specific boundary explains material delay, compare one bounded policy change at matched load. Use completion latency, achieved write throughput and tick latency as guardrails.

Preserve bounded admission, reservation release and history validation on the owner. Larger drains can delay consensus, other replies or shutdown; greater capacity can admit more detached I/O and retain more data. Use the parent's arrival model guidance so a slowing sequential client does not conceal the pressure being studied.

Start with the shared benchmark setup and evaluation criteria in #4174, then read core/shard/src/router.rs, core/shard/src/poll/completion.rs, and core/configs/src/server_config/sharding.rs. Reuse the parent stage capture and run a short concurrent-read ramp if warranted. Done means recording the requested load, admission, queue, memory, write-progress, and latency measures, with any policy comparison matched to guardrails.

Written by the indexing model from the issue text.