fix(mattermost): resolve thread follow-ups and tool output leaks (#4221)

[devorun]

What does this PR do?

Fixes #4221 — Mattermost threaded conversations broken in two ways.

1. Tool/reasoning output leaking to main channel
The send method now falls back to metadata.get("thread_id") when reply_to is not set, using it as root_id in the payload. All tool and processing output now stays inside the thread.

2. Follow-up messages ignored inside threads
Added _known_threads set to the adapter. When the bot posts into a thread, it registers that thread's ID. In _handle_ws_event, incoming messages from known threads bypass the @mention gate and continue the conversation naturally.

Related Issue

Fixes #

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

How to Test

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform:

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — or N/A
• I've updated cli-config.yaml.example if I added/changed config keys — or N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A
• I've updated tool descriptions/schemas if I changed tool behavior — or N/A

For New Skills

• This skill is broadly useful to most users (if bundled) — see Contributing Guide
• SKILL.md follows the standard format (frontmatter, trigger conditions, steps, pitfalls)
• No external dependencies that aren't already available (prefer stdlib, curl, existing Hermes tools)
• I've tested the skill end-to-end: hermes --toolsets skills -q "Use the X skill to do Y"

Screenshots / Logs

[teknium1]

Thanks for addressing both aspects of Mattermost thread usability. The thread-local delivery half has since landed on current main, but the unmentioned-follow-up behavior remains a distinct salvage target.

Problems

• gateway/platforms/mattermost.py:104 adds an unbounded, never-expiring _known_threads set. Every remembered root permanently bypasses the channel mention gate.
• gateway/platforms/mattermost.py:270 forwards reply_to directly as root_id; current main resolves a reply to its actual Mattermost root in plugins/platforms/mattermost/adapter.py:326-340.
• The branch silently changes the documented MATTERMOST_REQUIRE_MENTION=true behavior (website/docs/reference/environment-variables.md:433) and supplies no regression tests.

Suggested changes

• Port the remaining sticky-follow-up behavior to plugins/platforms/mattermost/adapter.py; the legacy target path was removed by af973e407.
• Use bounded/explicit sticky ownership and the current root-resolution helper, with tests for expiry and nested replies.

Automated hermes-sweeper review.

[teknium1]

This set is never bounded or expired, so a long-lived gateway retains every thread root and permanently bypasses mention gating for it. Please use bounded ownership/expiry semantics rather than process-lifetime membership.

[teknium1]

reply_to may be a reply post rather than the Mattermost thread root. Resolve it before assigning root_id; current main does this through _resolve_root_id() to avoid invalid-root errors.