fix(slack): clear stuck assistant status on /stop

[LeonSGP43]

Fixes #32295

Summary

• clear Slack assistant thread status from /stop even when no running agent is registered
• let SlackAdapter.stop_typing() clear a thread from explicit metadata when the in-memory chat_id -> thread_ts map is gone
• add regression tests for the metadata fallback and the Slack /stop no-active path

Testing

• uv run --frozen pytest -q -o addopts='' tests/gateway/test_slack.py -k 'stop_typing'
• uv run --frozen pytest -q -o addopts='' tests/gateway/test_slack_stop_command.py
• git diff --check
• uv run --frozen ruff check gateway/platforms/slack.py gateway/run.py tests/gateway/test_slack.py tests/gateway/test_slack_stop_command.py

[dhigginbotham]

Reviewed by Daemon. Requesting changes: the new Slack status clearing logic does not appear to cover the main /stop fast paths.

Blocking findings:

1. gateway/run.py:7036 — /stop while an agent is actively running is intercepted before normal command dispatch. That path calls _interrupt_and_clear_session(...) and returns an EphemeralReply, bypassing _handle_stop_command() where the new _clear_typing_indicator() helper lives. This can still leave Slack assistant/thread status stuck for the primary active-agent stop scenario.

2. gateway/run.py:7268 — the pending-agent /stop fast path also releases state and returns directly, bypassing the new clearing logic. If send_typing() has already set Slack status during startup/pending state, this can also leave status uncleared.

Targeted tests run by reviewer: python -m pytest tests/gateway/test_slack.py::TestSendTyping tests/gateway/test_slack_stop_command.py -q => 12 passed.

Suggested fix: call the Slack typing/status clear helper (or equivalent adapter stop_typing) in the active-running and pending-agent /stop fast paths as well, and add regression tests for both paths.

[teknium1]

Thanks for identifying the lost-map case. The issue is still present on current main, but the proposed placement does not reach the main /stop fast paths.

Problems

• Current main intercepts active-agent /stop at gateway/run.py:9257 and pending-agent /stop at gateway/run.py:9519, bypassing the PR's _handle_stop_command() helper. The active path reaches BasePlatformAdapter.interrupt_session_activity() which calls stop_typing(chat_id) without metadata (gateway/platforms/base.py:3931-3939); that cannot use the proposed fallback when Slack's map is absent.
• The Slack adapter has moved to plugins/platforms/slack/adapter.py:1544; /stop command handling is now in gateway/slash_commands.py:1054. This needs a port, not a clean application of the current diff.

Suggested changes

• Port the metadata fallback to plugins/platforms/slack/adapter.py, then route metadata-aware clearing through normal, active, and pending /stop paths.
• Add regressions for each of those paths with _active_status_threads absent.

Automated hermes-sweeper review.

[teknium1]

This helper is only reached through normal command dispatch. /stop while an agent is active or pending is intercepted earlier and returns without reaching this method, so the primary stuck-status paths remain uncovered. Please route the same metadata-aware clear through those fast paths and add regressions.

[teknium1]

Merged via #64621 — your commit was adapted onto current main with your authorship preserved in git log (dbd870467).

The core of your fix survived intact: /stop with no running agent now clears the stuck assistant status, and stop_typing clears a thread named in explicit metadata even when the in-memory tracking map has no entry (the gateway-restart case from #32295). It's rebuilt on top of the workspace-scoped status tracking that landed in #63709, with one added guard: when multiple Slack Connect workspaces track the same channel+thread and no team ID is provided, the clear is skipped rather than guessed.

Thanks @LeonSGP43!