… mixing (openclaw#10686)

* fix(slack): use thread-level sessions for channels to prevent context mixing

All messages in a Slack channel share a single session, causing context from
different threads to mix together. When users have multiple conversations in
different threads of the same channel, the agent sees combined context from
all threads, leading to confused responses.

Session key was: `slack:channel:${channelId}` (no thread identifier)

1. **Thread-level session keys**: Each message in channels/groups now gets
   its own session based on thread_ts:
   - Thread replies: use the parent thread's ts
   - New messages: use the message's own ts (becomes thread root)
   - DMs: unchanged (no thread-level sessions needed)

   New session key format: `slack:channel:${channelId}:thread:${threadTs}`

2. **Increased thread cache TTL**: Changed from 60 seconds to 6 hours.
   Users often pause conversations, and the short TTL caused unnecessary
   API calls and thread resolution failures.

3. **Increased cache size**: Changed from 500 to 10,000 entries to support
   busy workspaces with many active threads.

1. Create two threads in the same Slack channel
2. In Thread A: tell the bot your name is "Alice" and ask about "billing"
3. In Thread B: tell the bot your name is "Bob" and ask about "API"
4. Reply in Thread A and ask "what's my name?" - should say "Alice"
5. Check sessions: each thread should have a unique session key with :thread: suffix

Fixes context bleed issues related to #758

* fix(slack): also update resolveSlackSystemEventSessionKey for thread-level sessions

The context.ts file has a separate function for resolving session keys for
system events (reactions, file uploads, etc.). This also needs to support
thread-level sessions to ensure all Slack events route to the correct
thread-specific session.

Added threadTs and messageTs parameters to resolveSlackSystemEventSessionKey
and updated the implementation to use thread-level keys for channels/groups.

* fix(slack): preserve DM thread sessions for thread replies

The previous change broke thread-level sessions for DMs that have threads.
DMs with parent_user_id should still get thread-level sessions.

- For channels/groups: always use thread-level sessions
- For DMs: use thread-level sessions only when isThreadReply is true

* fix(slack): use thread-level sessionKey for previousTimestamp

Fixes the bug where previousTimestamp was read from the base channel
session key (route.sessionKey) instead of the resolved thread-level
sessionKey. This caused the elapsed-time calculation in the inbound
envelope to always pull from the channel session rather than the
thread session.

Also adds regression tests for the thread-level session key behavior.

Co-authored-by: Tony Dehnke <[email protected]>

* fix(slack): narrow openclaw#10686 to surgical thread-session patch

* test(slack): satisfy context/account typing in thread-session tests

* docs(changelog): record surgical slack thread-session fix

---------

Co-authored-by: Pablo Carvalho <[email protected]>
Co-authored-by: Tony Dehnke <[email protected]>
Co-authored-by: Tak Hoffman <[email protected]>
(cherry picked from commit 11d3470)