* fix(slack): include bot root message in new thread sessions (#79338)
When a user replies in-thread to a bot's own message in a Slack DM,
the new thread session was constructed without the parent/root message
content. The agent only saw `reply_to_id` metadata and could not
resolve what was being replied to, leading to confident-but-wrong
actions on follow-up corrections.
The thread-context resolver was filtering out every message authored
by the current bot before formatting thread history, including the
bot's own root message. For thread-replies starting a fresh session,
that left the agent without the parent context it needed.
This change retains current-bot messages in the thread history when
starting a new thread session, formats them with role=assistant under
a "Bot (this assistant)" sender label, and adds
`channels.slack.thread.includeRootMessage` (default `true`) to opt out.
Bot messages still bypass allowlist visibility filtering since the
bot's own output is not third-party content.
Fixes#79338.
* fix(slack): wire includeRootMessage into runtime config schema (#79338)
The first commit added `channels.slack.thread.includeRootMessage` to
the TypeScript type and zod schema, but the runtime AJV-style schema
generated from `extensions/slack/src/config-ui-hints.ts` rejected the
new field with `must NOT have additional properties` at gateway boot.
Adds the matching UI hint entry for `thread.includeRootMessage` and
regenerates the bundled channel config metadata so the live gateway
accepts the new field.
* Narrow Slack thread root context handling
Remove the public includeRootMessage config and keep the Slack thread fix focused on including only the current bot's root message on the first turn of a new thread session.
Preserve filtering of arbitrary current-bot Slack history while ensuring #79338 has parent/root context.
* Fix Slack thread root CI checks
---------
Co-authored-by: Bek <bek.akhmedov@gmail.com>
