…O(cap) (#722)

The enforce_retention_v2 boundary scan reverse-aggregates byte_size over every
deletable batch, O(partition depth). PR #705 moved it out of the log lock so it
no longer blocks commit, but the scan itself stayed O(depth): on a bulk drain
(retention lowered so almost the whole partition is deletable) a single scan on
a multi-million-batch partition runs for seconds-to-minutes and exceeds the
enforcer's socket.timeout.ms (default 5s), aborting the call and orphaning the
still-running backend so the partition never drains.

V22 caps the scan to the oldest (max_batches_per_request + 1) batches. The
boundary can never be deeper than the cap because the delete is clamped there
regardless; the +1 distinguishes an in-window boundary (delete up to it) from a
deeper one that falls through to high_watermark and is re-clamped by the
existing under-lock cap-probe. Each pass is O(cap), index-only on
batches_by_last_offset_covering_idx, and a deep partition drains over
successive enforcement cycles. max_batches_per_request = 0 keeps the original
unbounded full scan via LIMIT NULL. Correctness is unchanged from V21 (deletes
oldest-first, so a snapshot-stale boundary can only under-delete).

Flip retention.enforcement.max.batches.per.request default 0 -> 1000 so the
bound is on out of the box; it must stay above the per-interval expiry rate or
retention falls behind.

Benchmark (EnforceRetentionCommitBlockingBenchmarkTest, now cap-overridable via
-Dinkless.benchmark.maxBatchesPerEnforce). enforce ms vs depth at 200k/400k/800k
batches: unbounded 359/729/1465 ms (linear O(depth)); bounded cap=1 21/21/29 ms
(flat). A cap sweep shows per-pass cost is flat from cap 1 to 1000, so 1000 is
the sweet spot: short passes at 10x the drain throughput of 100.

[KC-354]

…O(cap) (#722)

The enforce_retention_v2 boundary scan reverse-aggregates byte_size over every
deletable batch, O(partition depth). PR #705 moved it out of the log lock so it
no longer blocks commit, but the scan itself stayed O(depth): on a bulk drain
(retention lowered so almost the whole partition is deletable) a single scan on
a multi-million-batch partition runs for seconds-to-minutes and exceeds the
enforcer's socket.timeout.ms (default 5s), aborting the call and orphaning the
still-running backend so the partition never drains.

V22 caps the scan to the oldest (max_batches_per_request + 1) batches. The
boundary can never be deeper than the cap because the delete is clamped there
regardless; the +1 distinguishes an in-window boundary (delete up to it) from a
deeper one that falls through to high_watermark and is re-clamped by the
existing under-lock cap-probe. Each pass is O(cap), index-only on
batches_by_last_offset_covering_idx, and a deep partition drains over
successive enforcement cycles. max_batches_per_request = 0 keeps the original
unbounded full scan via LIMIT NULL. Correctness is unchanged from V21 (deletes
oldest-first, so a snapshot-stale boundary can only under-delete).

Flip retention.enforcement.max.batches.per.request default 0 -> 1000 so the
bound is on out of the box; it must stay above the per-interval expiry rate or
retention falls behind.

Benchmark (EnforceRetentionCommitBlockingBenchmarkTest, now cap-overridable via
-Dinkless.benchmark.maxBatchesPerEnforce). enforce ms vs depth at 200k/400k/800k
batches: unbounded 359/729/1465 ms (linear O(depth)); bounded cap=1 21/21/29 ms
(flat). A cap sweep shows per-pass cost is flat from cap 1 to 1000, so 1000 is
the sweet spot: short passes at 10x the drain throughput of 100.

[KC-354]