fix(slack): resolve workspace token first for synthetic-thread sends

Addresses Codex P2 review on PR #212. When threadIsSynthetic is true,
sendMessage degenerates to a top-level channel post (no thread_ts), but
the token was still being resolved with getSlackBotToken(channelId,
threadId) first. In multi-workspace installs where a scheduled task/cron
fires before that channel has been seen by the message router, the
registry has no entry for the fake thread_ts and getSlackBotToken can
fall back to the first registered token instead of the token for
rawChannelId — leading to a follow-on channel_not_found / not_in_channel
even though dropping thread_ts was supposed to make the message
deliverable.

Mirror the token-resolution chain that sendChannelMessage already uses
for top-level posts:
  processor token -> workspace-by-channel token -> getSlackBotToken
for the synthetic path. The real-thread path is unchanged so registry
bindings for in-flight thread replies still win.

Tests: full suite still green (408 pass, 1 skip, 0 fail).

Author: Kai Liu

packages/ims/slack/client.ts

@@ -309,7 +309,6 @@ export async function sendMessage(
   const formattedText = markdownToSlack(text);
   const chunks = splitForSlack(formattedText);
   const workspace = slackAuthRegistry.getChannelWorkspaceName(rawChannelId) || "unknown";
-  const botToken = getSlackBotTokenForProcessor(processorId) ?? getSlackBotToken(channelId, threadId);
 
   // A "synthetic" thread id (`task:{id}` / `cron-job:{id}:{run}` / `cron:{id}`)
   // is an internal placeholder used by Ode's task/cron schedulers before a
@@ -320,6 +319,20 @@ export async function sendMessage(
   // the channel instead of being lost + captured as a Sentry error.
   const threadIsSynthetic = isSyntheticOwner(threadId);
 
+  // Token resolution. For real threads, prefer the registry-bound token for
+  // this (channel, thread) — that's the token the inbound router observed
+  // delivering the parent message and is the safest choice for replies. For
+  // synthetic placeholders the call has degenerated to a top-level channel
+  // post (see below); the registry has no entry for a fake `thread_ts`, so
+  // resolve via the channel's workspace first (mirrors `sendChannelMessage`)
+  // before falling back to `getSlackBotToken` to avoid the multi-workspace
+  // edge case where `getSlackBotToken` may return the first registered token
+  // instead of the one for `rawChannelId`.
+  const botToken = getSlackBotTokenForProcessor(processorId)
+    ?? (threadIsSynthetic
+      ? (getWorkspaceBotTokenForChannel(channelId) ?? getSlackBotToken(channelId))
+      : getSlackBotToken(channelId, threadId));
+
   if (!botToken) {
     log.warn("No Slack bot token available for channel", { channelId });
   }