#20244: resolution in DM with replyToMode=all

Slack: thread replies with replyToMode "all" when streaming is on With streaming enabled, agent replies and message-tool sends were posted as top-level messages in Slack DMs instead of under the incoming message, so replyToMode: "all" was ignored. Use the same thread target for starting the stream as for the streaming decision: when starting a stream, set streamThreadTs = replyPlan.nextThreadTs() ?? streamThreadHint so we always have a thread (e.g. messageTs in DMs) when streaming was enabled. When falling back to normal delivery due to no thread target, pass streamThreadHint into deliverNormally so the first message still threads. Add a test that resolveSlackStreamingThreadHint returns messageTs for replyToMode "all" and a top-level message (e.g. DM). Fixes the regression where DMs with replyToMode: "all" and streaming produced unthreaded replies. #19930 <!-- greptile_comment --> <h3>Greptile Summary</h3> Fixes a regression where Slack DMs with `replyToMode: "all"` and streaming enabled produced unthreaded replies. The stream-start path now falls back to `streamThreadHint` (the same thread target used to decide whether streaming is viable), ensuring the first streamed message is always posted as a thread reply in DMs. - In `deliverWithStreaming`, the stream thread target is now `replyPlan.nextThreadTs() ?? streamThreadHint`, so the thread hint computed for the streaming decision is reused when the reply plan returns `undefined`. - The `deliverNormally` fallback (when no thread target is found) now also receives `streamThreadHint` to preserve threading even in the non-streaming fallback path. - Adds a test confirming `resolveSlackStreamingThreadHint` returns `messageTs` for `replyToMode=all` on a top-level message (the DM case). - Import reordering groups type imports at the top of `dispatch.ts` (cosmetic). <h3>Confidence Score: 5/5</h3> - This PR is safe to merge — it's a small, well-targeted fix with correct logic and a covering test. - The change is minimal (two lines of logic + one test). The fallback `?? streamThreadHint` is logically sound: `streamThreadHint` is guaranteed to be defined whenever we're inside the streaming path (since `shouldUseStreaming` requires it). The `deliverNormally` fallback change is defensive but correct. The new test directly validates the previously-broken scenario. No regressions are introduced — the `replyPlan.nextThreadTs()` is still tried first, so existing behavior for non-DM and non-`all` modes is unchanged. - No files require special attention. _{Last reviewed commit: 921f16d} <!-- greptile_other_comments_section --> <!-- /greptile_comment -->