[BUG](worker): Revert the async fn window widening from #7621

[dbeglord]

The fn-consumer reads a window of log records between committed compaction boundaries. This restores it to stopping at the nearest committed boundary, rather than widening to the furthest boundary that still fits max_compaction_size.

Why

Widening makes job length swing up to the size cap instead of tracking a single compaction window, and max_compaction_size is the knob meant to tune that. The synthesis backend also splits large requests to stay under its own request-size limits, so a wider window gets split apart again downstream. This matches the decision made when #7621 was backed out of production on Aug 21.

Scope

Two files: the boundary-selection code and the tests that assert it.

#7621 also carried cleanups unrelated to window selection — a chunks_exact(N) → as_chunks::<N>() migration across the index and types crates, and two drain(..).collect() → std::mem::take call sites. Those stay. The diff here is the exact inverse of #7621 for the two files it touches, and nothing else has modified them since it merged.

Production context

This behavior is already absent from production. It was hotfixed onto release/2026-08-18 and then reverted there, but the matching revert never landed on main — so it is present in release/2026-08-31, and promoting that branch would reintroduce it.

Once this merges, a cherry-pick onto release/2026-08-31 (via the apply-hotfix workflow) closes the second path, ahead of the production promotion.

Validation

cargo check -p worker --tests passes.

🤖 Generated with Claude Code

[claude]

Claude Code Review

This repository is configured for manual code reviews. Comment @claude review for a one-time review, or @claude review always to subscribe this PR to a review on every future push.

_{Tip: disable this comment in your organization's Code Review settings.}

[github-actions]

Reviewer Checklist

Please leverage this checklist to ensure your code review is thorough before approving

Testing, Bugs, Errors, Logs, Documentation

• Can you think of any use case in which the code does not behave as intended? Have they been tested?
• Can you think of any inputs or external events that could break the code? Is user input validated and safe? Have they been tested?
• If appropriate, are there adequate property based tests?
• If appropriate, are there adequate unit tests?
• Should any logging, debugging, tracing information be added or removed?
• Are error messages user-friendly?
• Have all documentation changes needed been made?
• Have all non-obvious changes been commented?

System Compatibility

• Are there any potential impacts on other parts of the system or backward compatibility?
• Does this change intersect with any items on our roadmap, and if so, is there a plan for fitting them together?

Quality

• Is this code of a unexpectedly high quality (Readability, Modularity, Intuitiveness)