#23086: fix(cron): surface channel resolution error for isolated sessions with no history

Fixes #22795. When a cron job uses `sessionTarget: "isolated"` without an explicit `channel` in the config, the first run has no session history to fall back on. `resolveDeliveryTarget` calls `resolveMessageChannelSelection` to figure out which channel to use — but with multiple channels configured this throws `"Channel is required when multiple channels are configured"`. The `catch` block swallowed that error and silently defaulted to `DEFAULT_CHAT_CHANNEL` (`"whatsapp"`), delivering to the wrong channel with no warning. `run.ts` already handles `resolvedDelivery.error` correctly at line ~596 (hard error or logged warning depending on `bestEffort`). The error just wasn't reaching it. ## What changed `src/cron/isolated-agent/delivery-target.ts` — two small changes: 1. In the `catch` block: capture the error in `channelResolutionError` when there is no session `lastChannel` to fall back on. If `lastChannel` exists the right channel was used, so no error. 2. Pass `channelResolutionError` through both return paths (the early `!toCandidate` return and the final `docked` return) so it reaches the caller. The early `!toCandidate` return is the path first-run isolated sessions take when there is no delivery target yet — that path also needed the error. ## Tests - New: multi-channel config + no session history → `result.error` contains the channel resolution error - New: multi-channel config + session has `lastChannel` → `result.error` is undefined (existing behavior preserved) - Existing 12 tests unchanged Closes #22795 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> <!-- greptile_comment --> <h3>Greptile Summary</h3> Fixes a silent channel misroute for isolated cron sessions with no history. When `resolveMessageChannelSelection` threw (e.g., multiple channels configured, no explicit channel), the catch block swallowed the error and silently defaulted to `DEFAULT_CHAT_CHANNEL` (`"whatsapp"`). The caller in `run.ts` already handles `resolvedDelivery.error` correctly (hard error or logged warning depending on `bestEffort`), but the error was never reaching it. - Captures the channel resolution error in the `catch` block when no session `lastChannel` exists to fall back on - Propagates `channelResolutionError` through both return paths: the early `!toCandidate` return (first-run isolated sessions) and the final `docked` return - When `lastChannel` exists, the known-good channel is used and no error is surfaced (preserving existing behavior) - Adds two focused tests covering both the error and no-error paths <h3>Confidence Score: 5/5</h3> - This PR is safe to merge — it's a minimal, well-scoped bug fix that surfaces an error that was previously swallowed. - The changes are small and focused: one new local variable, one conditional assignment in a catch block, and two return-path additions. The logic is straightforward — only surface the error when there's no session lastChannel to fall back on. Error precedence between channelResolutionError and docked.error is handled correctly. The caller in run.ts already handles the error field properly. Two new tests cover the exact scenarios. Existing tests pass unchanged. - No files require special attention _{Last reviewed commit: 164f686} <!-- greptile_other_comments_section --> <!-- /greptile_comment -->