#20274: fix: add fallback delivery when stopSlackStream fails

## Summary - Adds `deliverNormally()` fallback in the `stopSlackStream()` catch block so agent response text is delivered via normal API when streaming stop fails - Uses `finalStream.threadTs` to route the fallback reply to the correct thread - Mirrors the existing fallback pattern already used in the `appendSlackStream()` error path ## Problem The Slack streaming delivery pipeline has two error paths. When `appendSlackStream()` fails (~line 23759 in dist), the code falls back to `deliverNormally()` — working correctly. But when `stopSlackStream()` fails (~line 23901 in dist), the error is logged but no fallback delivery occurs, silently dropping the agent's response. This was triggered by `missing_recipient_team_id` errors from Slack's streaming API, but any streaming stop failure would expose the same bug. ## Test plan - [ ] Send @mention in a channel known to trigger `missing_recipient_team_id` on streaming - [ ] Verify response is delivered via fallback when stream stop fails - [ ] Check logs for `"slack-stream: fallback delivery succeeded to thread"` message - [ ] Verify normal streaming delivery still works on channels without the error Fixes #20273 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- greptile_comment --> <h3>Greptile Summary</h3> This PR adds a fallback delivery path when `stopSlackStream()` fails, mirroring the existing fallback in the `appendSlackStream()` error path. The intent is correct — when the streaming stop API fails, the agent's response should be delivered via normal Slack API. However, **the fallback is broken due to a type mismatch**: `queuedFinal` is a `boolean` (from `DispatchFromConfigResult`), not a `ReplyPayload`. Passing it to `deliverNormally()` means the reply content will be silently dropped rather than delivered. - **Critical bug on line 406**: `deliverNormally(queuedFinal, finalStream.threadTs)` passes a boolean where a `ReplyPayload` is expected. This means `.text` resolves to `undefined` and the message is skipped entirely in `deliverReplies`. - The fix needs a mechanism to capture the actual last reply payload (e.g., storing it during the streaming delivery flow) so it can be re-sent in this fallback path. <h3>Confidence Score: 1/5</h3> - This PR introduces a non-functional fallback path due to a type mismatch that will silently drop messages instead of delivering them. - The core change passes a boolean (`queuedFinal`) to a function expecting a `ReplyPayload` object. This means the fallback delivery will never actually send the agent's response — it will silently succeed without delivering any text. The intent of the PR (ensuring messages are delivered when streaming stop fails) is not achieved, and it may provide a false sense of reliability since the log message "fallback delivery succeeded" will still print. - `src/slack/monitor/message-handler/dispatch.ts` — the fallback delivery on line 406 passes wrong argument type _{Last reviewed commit: 69fcf84} <!-- greptile_other_comments_section --> _{(3/5) Reply to the agent's comments like "Can you suggest a fix for this @greptileai?" or ask follow-up questions!} <!-- /greptile_comment -->