Greptile Summary

This PR fixes a cross-channel reply routing bug (#45514) where, in same-provider multi-channel setups (e.g., two Slack channels monitored by one agent), the collect-mode batch reply could be routed to the wrong channel. The root cause was that resolveOriginRoutingMetadata() made four independent .find() calls — one per routing field — which could draw each field from a different queue item when a batch spans multiple channels.

Key changes:

• resolveOriginRoutingMetadata now selects a single source item once and reads all four routing fields (originatingChannel, originatingTo, originatingAccountId, originatingThreadId) from that same item, eliminating any possibility of cross-item field mixing.
• Three regression tests are added in drain.test.ts covering: (1) two-channel individual routing, (2) same-channel batch-collect consistency, and (3) mixed account/channel field isolation.

Note: The PR description states "Added 15 regression tests" — the test file actually contains 3 test cases (with roughly 15 expect() assertions across them). This is a description inaccuracy, not a code concern.

Confidence Score: 5/5

• Safe to merge — the fix is logically sound, well-commented, and the tests exercise the critical regression path.
• The fix correctly consolidates all routing field reads onto a single source item. Analysis of the full code path confirms this is safe: resolveOriginRoutingMetadata is only reached after hasCrossChannelItems has guaranteed remaining batch items share the same routing key (or have no routing at all), so the new single-source selection produces the same result as the old per-field independent selection for all currently reachable code paths — while also being strictly correct if that guard ever changes. Tests are clear and cover the bug scenario directly.
• No files require special attention.

_{Reviews (1): Last reviewed commit: "fix(routing): prevent cross-channel repl..." | Re-trigger Greptile}