…space leak (NousResearch#12421)

``SlackAdapter._fetch_thread_context`` cached rendered context under
``f"{channel_id}:{thread_ts}"`` but the rendered content is
workspace-scoped — bot-mention stripping uses
``_team_bot_user_ids[team_id]`` and user-name resolution routes
through ``_get_client(channel_id)`` (which in turn consults
``_channel_team``).  A later lookup from a different workspace for
the same ``(channel_id, thread_ts)`` tuple therefore receives stale
context rendered for the first workspace.

Multi-workspace Slack mode (``_team_clients``, ``_team_bot_user_ids``,
``_channel_team``) is explicitly supported elsewhere in the adapter,
so ignoring ``team_id`` in this one cache is a clear omission rather
than a design choice.  Reporter: NousResearch#12421.

Reporter's exact repro reproduces on clean ``origin/main`` (``6fb69229``)::

    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   # FAILS — both equal T1's content

Fix
---
Include ``team_id`` in the cache key:

    cache_key = f"{team_id}:{channel_id}:{thread_ts}"

Empty ``team_id`` (single-workspace legacy callers) falls into its
own namespace (key starts with ``":"``), backward-compatible with
existing test harnesses and zero-team deployments.

Behaviour matrix
----------------
| Call                                          | Before                                 | After                                        |
| --- | --- | --- |
| T1 then T2, same ``(channel, thread_ts)``     | second call cache-hits → T1's content  | each workspace gets its own fetch + content |
| T1 twice, same ``(channel, thread_ts)``       | cache hit (unchanged)                  | cache hit (unchanged)                        |
| T1 then T1, different channels                | separate entries (unchanged)           | separate entries (unchanged)                 |
| ``team_id=""`` then ``team_id="T1"``          | same key (``"C:ts"``) — collision      | distinct keys (``":C:ts"`` vs ``"T1:C:ts"``) |
| TTL expiry on T1's entry                       | evicts shared entry                    | evicts T1's entry only; T2 still cached      |

Narrow scope — explicitly not changed
-------------------------------------
* **``_user_name_cache``** (line 87).  Also keyed solely by
  ``user_id``.  Slack user IDs are globally unique across the
  platform, so standard multi-workspace operation doesn't collide
  there — but in Enterprise Grid where a single user has different
  display names per workspace, this cache *could* serve a stale
  name.  Out of scope for this PR (separate fix, separate test
  surface); noted here for the reviewer's investigation.
* **``_assistant_threads``** (line 111).  Keyed by
  ``(channel_id, thread_ts)``.  Channel IDs are distinct per
  workspace in standard multi-workspace mode, so no collision
  occurs in practice.  Left unchanged.
* **Other Slack caches/routing maps**.  Audited; only
  ``_thread_context_cache`` and the Enterprise Grid edge case on
  ``_user_name_cache`` exhibit the team-unaware pattern.  Reporter's
  "Suggested Investigation Direction" resolved as above.

Regression coverage
-------------------
``tests/gateway/test_slack_approval_buttons.py`` gets a new
``TestSlackThreadContextWorkspaceIsolation`` class with 7 cases
backed by a ``_make_multi_workspace_adapter()`` helper:

* ``test_reporter_repro_two_workspaces_do_not_share_cache`` —
  exact issue-body repro.
* ``test_same_workspace_same_thread_uses_cache`` — preserved-
  behaviour canary (cache hit within one workspace still saves an
  API call).
* ``test_structural_pin_cache_key_contains_team_id`` — asserts the
  concrete cache key shape contains the team_id AND the old
  workspace-unaware key is not populated; guards against future
  regressions silently stripping the team component.
* ``test_mention_stripping_is_team_specific`` — each workspace
  returns text containing *both* bots' mentions; after per-
  workspace stripping, T1's output has only T2's mention and vice
  versa.  Proves the bug affects rendered content, not just cache
  identity.
* ``test_ttl_is_per_workspace`` — artificially ages one team's
  entry past TTL; asserts only that team re-fetches while the
  other stays cached.
* ``test_empty_team_id_has_own_namespace`` — backward-compat for
  legacy callers passing ``team_id=""``.
* ``test_different_channels_same_team_each_get_cached`` — sanity
  canary: within one workspace, different channels still get
  distinct entries (no cross-channel collapsing).

6 of the 7 fail on clean ``origin/main`` with KeyError on the new
key shape or assertion errors on cross-workspace content leak.  The
1 that passes on main is the preserved-behaviour canary — it
guarantees the fix doesn't over-correct into per-call fetches.

Validation
----------
``source venv/bin/activate && python -m pytest
tests/gateway/test_slack_approval_buttons.py::TestSlackThreadContextWorkspaceIsolation
-q`` → **7 passed**.

Broader Slack + session suites
(``tests/gateway/test_slack*.py`` + ``test_session.py`` +
``test_session_dm_thread_seeding.py``) under ``-n auto`` →
**249 passed, 0 failures**.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

…t frozen (follow-up to NousResearch#12421)

Copilot review caught that the comment in
``test_ttl_is_per_workspace`` said ``dataclasses.replace`` was used
"to avoid mutating a frozen dataclass" — but
``_ThreadContextCache`` is a regular ``@dataclass``, not frozen.

Reworded to reflect the real reason for using ``dataclasses.replace``:
keeping the test intent (rebuild an entry with an aged timestamp)
explicit at the call site rather than mutating ``t1_entry.fetched_at``
in place.

No behaviour change.  7 passed, same as before.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>