Route triage and audit automations to any comms destination

[daniel-lxs]

What

Sixth PR of the "automations on all comms channels" track (follows #280, #281, #284, #285, #289). This is the one where non-Slack destinations actually light up: Sentry triage, Dependabot triage, and the security/code-quality auditors can now report to Teams or Telegram.

Design

Rather than teaching every runner about communication adapters, the resolved destination is stamped onto the scan task's communication payload fields (communicationProvider/ChannelId/ServiceUrl) at enqueue. Everything downstream then works unchanged: the worker converts those to envs, the surface-generic tools (send_chat_reply, post_to_channel from #285) register and dispatch correctly, and the own-conversation posting restriction naturally scopes the task to its destination. Slack destinations are deliberately unstamped — their scan tasks keep the existing arbitrary-channel post_to_slack_channel flow byte-for-byte.

• Destination resolution (packages/sdk/src/server/automations/destination.ts): extends the db-level waterfall (automation's own target → Slack manager channel) with a primary-conversation tail for Slack-less deployments — most recently active Teams conversation, then the Telegram primary chat. The tail is skipped when Slack is connected, so a Slack deployment that just hasn't picked a manager channel keeps its explicit nudge instead of surprising another surface. Teams destinations resolve their Bot Framework serviceUrl from teamsInstallations (indexed lookup) at launch; unresolvable serviceUrl means no destination rather than a broken one.
• Runner eligibility: deployments without Slack are now eligible when any comms provider is connected (listConnectedCommunicationProviders, the piece deferred since Add generic communication adapter dispatch #281). Slack-only side effects (routing debug posts, workspace timezone) are guarded on an actual bot token.
• Prompts are surface-correct: channel tag, posting tool name, and destination wording parameterized per provider across the four automations' scan prompts.
• Gates: manual "Run now" and the settings-save validation accept a resolved destination on any provider the automation's descriptor supports; Slack-only automations (announcer, manager_stats, suggester) keep their exact current behavior and errors. Registry capability declarations flip to ['slack','teams','telegram'] for the four generalized automations.
• ci_failure_triage explicitly skips non-Slack destinations with a clear reason — its prompt and webhook announcement path are still Slack-shaped; it generalizes in a follow-up along with announcer/manager-stats (which post directly via SlackNotifier with Block Kit and need message degradation, tracked as PR 6b).

Testing

• New destination-module suite (11 tests): waterfall order, connected-provider listing, serviceUrl resolution and its failure mode, Slack-nudge preservation, Teams/Telegram tails, payload stamping, prompt context
• Full local runs green: types (529), db (257), sdk (469), web (1947), api (906); lint/types/knip pass
• Live Teams validation on the dev stack is the remaining step before this should merge

🤖 Generated with Claude Code

[roomote-roomote]

No new code issues found. Both earlier notes are addressed in the latest changes. See task

• packages/sdk/src/server/automations/scheduled-triage-runner.ts:101 — the Slack-less skip reason now reads 'No connected communication provider.', which is accurate for the triage runner (its eligibility gate only checks connected comms providers; GitHub is gated per-automation inside buildScanTask).
• packages/sdk/src/server/automations/sentry-triage.ts:157, dependabot-triage.ts:96, merged-pr-audit-runner.ts:419 — the feedback lookups now pass surface: destination.provider, and loadAutomationThreadFeedback* forwards it to the surface filter, so Teams/Telegram destinations match their own tracked threads. The reply-harvesting gap (feedback replies still read from the Slack conversation log only) is now explicitly documented in background-automation-slack-threads.ts as a follow-up.

_{Reviewed c9b3590}