Bug Description

SlackAdapter._fetch_thread_context() caches thread context under f"{channel_id}:{thread_ts}", but the rendered content is team-specific: it depends on team_id for bot mention stripping and user-name resolution. In multi-workspace Slack mode, a later lookup from a different workspace can receive stale context from the first workspace instead of re-fetching/rendering with that workspace's identity data.

Affected Files / Lines

• gateway/platforms/slack.py:1433-1437
• gateway/platforms/slack.py:1478-1516

Why This Is a Bug

The adapter explicitly supports multiple workspaces (_team_clients, _team_bot_user_ids, _channel_team), but the cache key ignores team_id. That means the cache can serve content that was produced for a different workspace even though the output depends on workspace-scoped state.

Minimal Reproduction

A minimal in-repo reproduction shows the second call reusing the first workspace's cached content and skipping the API call entirely:

first = await adapter._fetch_thread_context('Csame', '1000.0', '9999.9', team_id='T1')
second = await adapter._fetch_thread_context('Csame', '1000.0', '9999.9', team_id='T2')
assert first == second
assert client.conversations_replies.await_count == 1

Observed output on the second call still contained Alice1 / Bob1 from the first workspace instead of the second workspace's resolver output.

Expected Behavior

Thread-context cache entries should be isolated per workspace (for example by including team_id in the cache key), so a lookup for workspace B cannot reuse workspace A's rendered context.

Actual Behavior

A lookup for a different workspace can return stale cached context rendered for the previous workspace.

Suggested Investigation Direction

• Include team_id in the thread-context cache key.
• Audit other Slack caches/routing maps that currently key only on channel_id.