Depends on #57970 (fix/mattermost-unknown-chat-type). This branch is rebased on that PR. After #57970 merges, this PR should be rebased onto main.

With replyToMode: "off", resolveMattermostEffectiveReplyToId returns undefined
to prevent thread session forking. However, this also broke two delivery behaviours
that depended on effectiveReplyToId being set:

1. MessageThreadId was always undefined in the inbound context, so tools and
   plugin hooks had no way to know which thread a message came from.

2. Agent replies went to the main channel instead of the originating thread, because
   all three deliver call sites passed effectiveReplyToId (undefined) as the
   threadRootId to resolveMattermostReplyRootId. Plugin command responses share
   the same deliver path and are affected by the same bug.

Fix:

• resolveMattermostThreadSessionContext now computes messageThreadId separately
  as post.root_id ?? effectiveReplyToId, reflecting the actual thread root
  regardless of replyToMode.
• MessageThreadId in the inbound ctxPayload is now set from messageThreadId
  at all three dispatch sites (interaction, model-picker/sendMessage, main handler).
• All three resolveMattermostReplyRootId deliver call sites now pass
  messageThreadId as threadRootId instead of effectiveReplyToId, so replies
  are delivered to the correct thread.
• All three sendTypingIndicator call sites now pass messageThreadId so typing
  indicators appear in the same thread as the eventual reply.
• Added buildToolContext to the Mattermost threading config so that
  currentThreadTs is populated from MessageThreadId, giving agent tools
  visibility into the active thread.
• Fixed resolveThreadFlag in src/config/sessions/reset.ts to not classify a
  session as thread-scoped when messageThreadId is set but the session key
  explicitly identifies a group/channel session. messageThreadId is a delivery
  detail; the session key is authoritative for session type.
• Removed the channelTypeKnown workaround from handlePost — now dead code
  because the kind === "unknown" early-exit guard from fix(mattermost): return 'unknown' ChatType when channel type is not resolvable #57970 prevents reaching
  the threading logic with an unresolved channel type.

Summary

• Problem: With replyToMode: "off", any message posted inside a Mattermost
  thread caused effectiveReplyToId to be undefined. All three deliver call sites
  used effectiveReplyToId as the thread root for outgoing replies, so agent replies
  posted to the main channel instead of the originating thread. Plugin command
  responses share the same deliver path and are affected identically. Additionally,
  ctx.MessageThreadId was always undefined, so tools had no visibility into the
  active thread.
• Why it matters: Users with replyToMode: "off" (the typical setup for bots
  that should not fork per-thread sessions) could not use Mattermost threads at all
  — every agent reply landed in the main channel instead of the thread it came from.
• What changed: resolveMattermostThreadSessionContext now returns a separate
  messageThreadId field (post.root_id ?? effectiveReplyToId) that carries the
  actual thread root independent of replyToMode. All three deliver call sites,
  all three typing indicator call sites, and all three ctxPayload construction
  sites now use messageThreadId instead of effectiveReplyToId.
  buildToolContext added to the Mattermost threading config so currentThreadTs
  is populated. resolveThreadFlag updated to treat messageThreadId as a
  delivery detail rather than a session-type signal when the session key is
  explicitly a group/channel session. Removed the channelTypeKnown workaround
  (dead code after fix(mattermost): return 'unknown' ChatType when channel type is not resolvable #57970).
• What did NOT change: Session routing is unaffected — effectiveReplyToId and
  resolveThreadSessionKeys are unchanged, so replyToMode: "off" still prevents
  thread session forking exactly as intended.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Depends on fix(mattermost): return 'unknown' ChatType when channel type is not resolvable #57970 (fix/mattermost-unknown-chat-type)
• Related feat(mattermost): add replyToMode support (off | first | all) #29587 (feat: add replyToMode support)
• This PR fixes a bug or regression

Root Cause / Regression History (if applicable)

• Root cause: effectiveReplyToId was serving two distinct purposes — session
  routing (which session key to use) and delivery routing (where to post the reply).
  Commit aaba1ae653 correctly set it to undefined for session routing when
  replyToMode: "off", but inadvertently broke delivery routing as a side effect.
• Missing detection / guardrail: Tests for resolveMattermostThreadSessionContext
  only asserted on effectiveReplyToId and sessionKey. No test covered the
  end-to-end delivery path (deliver callback → resolveMattermostReplyRootId →
  actual post target) for the replyToMode: "off" + threaded message scenario.
• Prior context: replyToMode support was added in 2026.3.12 (171d2df9e0,
  PR feat(mattermost): add replyToMode support (off | first | all) #29587). The regression was introduced in 2026.3.22 by aaba1ae653.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: extensions/mattermost/src/mattermost/monitor.test.ts,
  resolveMattermostThreadSessionContext describe block
• Scenario the test should lock in: When replyToMode: "off" and a non-zero
  threadRootId is present, messageThreadId equals threadRootId and
  effectiveReplyToId is still undefined.
• Existing test that already covers this: Added
  "still reports messageThreadId when replyToMode is off" in this PR; also updated
  the existing "keeps threaded messages top-level when replyToMode is off"
  assertion to include messageThreadId: "root-456".

User-visible / Behavior Changes

With replyToMode: "off", agent replies now go to the originating thread instead
of the main channel. Typing indicators appear in the same thread. Plugin command
responses are also fixed as they share the same delivery path. No change in
behaviour for replyToMode: "all" or "first".

Diagram (if applicable)

Before (replyToMode: "off", user posts inside thread T1):
  post.root_id="T1"
    -> effectiveReplyToId=undefined
    -> resolveMattermostReplyRootId(threadRootId=undefined, replyToId=undefined)
    -> reply posts to main channel  ✗

After:
  post.root_id="T1"
    -> messageThreadId="T1"   effectiveReplyToId=undefined (unchanged)
    -> resolveMattermostReplyRootId(threadRootId="T1")
    -> reply posts to thread T1  ✓
    -> session key unchanged (no forking)  ✓
    -> resolveThreadFlag: session key is ":channel:" → isThread=false  ✓

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No

Repro + Verification

Environment

• Integration/channel: Mattermost, account with replyToMode: "off"
• Relevant config: channels.mattermost.replyToMode: "off" (or per-account equivalent)

Steps

1. Configure a Mattermost account with replyToMode: "off"
2. Post a message inside a channel thread
3. Observe where the agent reply appears

Expected

• Agent reply appears inside the thread

Actual (before fix)

• Agent reply appears in the main channel

Human Verification (required)

• Verified on unpatched 2026.3.28: with replyToMode: "off", agent replies land in
  the main channel instead of the originating thread. Confirmed fixed with this PR.
• Typing indicators also appear in-thread after fix.
• Edge cases checked: top-level messages with replyToMode: "off" unaffected;
  replyToMode: "all" behaviour unchanged.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No

Risks and Mitigations

• Risk: messageThreadId used where effectiveReplyToId was previously undefined
  for replyToMode: "all"/"first" top-level posts — could change delivery target.
  • Mitigation: messageThreadId = threadRootId ?? effectiveReplyToId, so for
    non-"off" modes the value is identical to the old effectiveReplyToId. No
    behaviour change for those modes.
• Risk: setting MessageThreadId could misclassify channel sessions as thread
  sessions in resolveThreadFlag, changing reset policy for users with separate
  session.resetByType.thread config.
  • Mitigation: fixed in src/config/sessions/reset.ts — resolveThreadFlag now
    defers to the session key when it explicitly identifies a group/channel session,
    treating messageThreadId as a delivery detail rather than a session-type signal.