fix(pixel-layout): prevent OOM by limiting queued page futures

[samiuc]

PixelLayoutEvaluator.__call__ submitted all futures for the entire dataset before collecting any results:

# Before: submit all, then collect all
for data in ds_selection:        # e.g. 981 documents
    futures.extend(submit(...))  # all queued in memory simultaneously

for future in as_completed(futures):
    collect(future)

Each in-flight page future holds a serialized (height × width) uint64 numpy array (~8 bytes/pixel) queued for the worker process. On datasets with large pages (e.g. OmniDocBench at ~145 M pixels/page), with concurrency=4, peak memory reaches 4 workers × 2 arrays × ~1.16 GB = ~9 GB, exhausting RAM and killing the process.

The PR:

• Replaces the two-pass pattern with a bounded sliding window: at most concurrency × 2 futures are in-flight at once. Completed futures are drained inline before new ones are submitted, so peak memory is proportional to concurrency rather than dataset size.
• Extract the result-accumulation logic into a _collect_page_result static method (previously an inline closure with nonlocal) for clarity and testability.

[github-actions]

✅ DCO Check Passed

Thanks @samiuc, all your commits are properly signed off. 🎉

[mergify]

Merge Protections

Your pull request matches the following merge protections and will not be merged until they are valid.

🟢 Enforce conventional commit

Wonderful, this rule succeeded.

Make sure that we follow https://www.conventionalcommits.org/en/v1.0.0/

• title ~= ^(fix|feat|docs|style|refactor|perf|test|build|ci|chore|revert)(?:\(.+\))?(!)?:

[PeterStaar-IBM]

lgtm!

[laurachiticariu]

@PeterStaar-IBM can this be reviewed and merged?