#16259: fix(cron): pass accountId through delivery path for multi-account channels

## Problem The `accountId` field in cron job delivery configs was never wired through the delivery resolution path. This caused cron jobs targeting multi-account channels (e.g., WhatsApp) to always fall back to the `default` account, even when a specific account was configured. **Error observed:** ``` Error: No active WhatsApp Web listener (account: default) ``` **Expected:** Use the `accountId` specified in the cron job's delivery config. **Cron job config that failed:** ```json "delivery": { "mode": "announce", "channel": "whatsapp", "to": "120363039837971321@g.us", "accountId": "flickclaw" } ``` ## Root Cause Three locations where `accountId` was missing: 1. `CronDelivery` type didn't include `accountId` 2. `resolveCronDeliveryPlan()` didn't extract `accountId` from the job config 3. `resolveDeliveryTarget()` wasn't passed the explicit `accountId` ## Changes | File | Change | |------|--------| | `src/cron/types.ts` | Added `accountId?: string` to `CronDelivery` | | `src/cron/delivery.ts` | Extract `accountId` in `resolveCronDeliveryPlan()`, include in return | | `src/cron/isolated-agent/delivery-target.ts` | Accept `accountId` param, prefer explicit over session-derived | | `src/cron/isolated-agent/run.ts` | Pass `deliveryPlan.accountId` to `resolveDeliveryTarget()` | | `src/gateway/protocol/schema/cron.ts` | Added `accountId` to `CronDeliverySchema` and `CronDeliveryPatchSchema` | | `src/agents/tools/cron-tool.ts` | Updated tool description to document `accountId` option | | `src/cron/delivery.test.ts` | Added tests for `accountId` extraction | ## Testing - Added unit tests for `accountId` extraction in `resolveCronDeliveryPlan()` - Verified the fix resolves the WhatsApp delivery issue for named accounts <!-- greptile_comment --> <h3>Greptile Summary</h3> This PR correctly wires the `accountId` field through the cron delivery pipeline, fixing a bug where multi-account channels (e.g., WhatsApp) always fell back to the `default` account. The changes add `accountId` to the `CronDelivery` type, extraction logic in `resolveCronDeliveryPlan()`, the delivery target resolver, and the gateway validation schemas. - Adds `accountId?: string` to `CronDelivery` type and `CronDeliveryPlan` - Extracts `accountId` from delivery config with proper `normalizeAccountId` helper that mirrors the existing `normalizeTo` pattern - `resolveDeliveryTarget()` now accepts and prefers an explicit `accountId` over the session-derived value — correctly addressing the root cause - Schema validation uses `NonEmptyString` to prevent empty strings at the API boundary - Unit tests cover both the presence and absence of `accountId` - **Gap found**: `mergeCronDelivery()` in `src/cron/service/jobs.ts` (not modified in this PR) does not preserve or merge `accountId`, so updating any delivery field on an existing cron job will silently drop a previously-set `accountId` <h3>Confidence Score: 3/5</h3> - The core fix is correct, but `mergeCronDelivery` does not handle `accountId`, meaning job updates will silently drop the field. - The changes in this PR are well-structured and correctly wire `accountId` through the delivery path for job creation and execution. However, the omission of `accountId` handling in `mergeCronDelivery` (src/cron/service/jobs.ts) means cron job patch/update operations will silently discard the field. This is a functional gap that will cause confusion when users update cron jobs — the `accountId` will be lost and the job will revert to the default account. - `src/cron/service/jobs.ts` — `mergeCronDelivery` function needs `accountId` handling to complete this fix _{Last reviewed commit: 42f6cb2} <!-- greptile_other_comments_section --> <!-- /greptile_comment -->