fix(slack): re-apply bang→slash rewrite after @mention strip

[zenplace-system]

Problem

When a user types @bot !model ... (or any !cmd prefixed with an @mention) in a Slack channel, the !→/ rewrite that normally fires for bare !cmd messages is silently skipped.

Root cause

The bang-rewrite pass (around line 2298) guards on original_text.startswith("!").
When the message starts with <@BOT_UID>, that condition is false and the rewrite never runs.
After mention-stripping (line 2527) the text becomes !model ..., but there is no second rewrite pass — so the message arrives at the dispatcher as plain TEXT instead of COMMAND.

Reproducer

Send @bot !model jp.anthropic.claude-opus-4 --provider bedrock in a Slack channel.
Expected: model switches (or asks for confirmation).
Actual: silently ignored / treated as free text.

Fix

After stripping the bot mention, check whether the resulting text starts with ! and, if is_gateway_known_command resolves it, rewrite it to /cmd ... and sync original_text so the downstream MessageType.COMMAND detection fires correctly.

The added code reuses the exact same logic that already exists for the bare-! path, keeping behaviour identical.

Testing

• Existing Slack test suite passes (failures in test_slack_channel_session_scope and test_help_returns_command_list are pre-existing and unrelated to this change — confirmed by running baseline on main before the patch).
• Manually verified the rewrite logic with a Python reproducer:

text = '<@UBOT123> !model jp.anthropic.claude-opus-4-8 --provider bedrock'
# After mention strip:
# → '!model jp.anthropic.claude-opus-4-8 --provider bedrock'
# After bang rewrite (new code):
# → '/model jp.anthropic.claude-opus-4-8 --provider bedrock'  ✅

[alt-glitch]

Duplicate of #30592 — that PR (open, filed earlier) adds the identical bang->slash re-rewrite block after mention-stripping in slack.py, with byte-equivalent logic (same is_gateway_known_command guard and original_text sync). #30592 also fixes a second bug (thread-context prepend breaking the is_command() slash check), so it is the broader, canonical fix.

[teknium1]

Thanks for isolating a real Slack command-routing gap.

Problems

• Current main moved the runtime adapter from gateway/platforms/slack.py to plugins/platforms/slack/adapter.py in 5600105478ffde29d7566b45421b100eaa29c4ef; this hunk therefore cannot reach the active adapter.
• The re-rewrite uses post-augmentation text. Current Slack processing appends rich-block content before mention stripping (plugins/platforms/slack/adapter.py:2655-2672), so quoted content can become command arguments.
• First-thread context is still prepended at plugins/platforms/slack/adapter.py:2886-2900. MessageEvent.is_command() requires the final text to start with / (gateway/platforms/base.py:1805-1807), so this can still prevent dispatch.
• No regression test covers @bot !cmd; existing coverage is bare-bang only (tests/gateway/test_slack.py:1145-1201).

Suggested changes

• Port the logic to the plugin adapter, normalize mention-stripped raw text, bypass context prepend for commands, and add the focused regressions. The member-linked #30592 already targets this architecture and covers these cases.

Automated hermes-sweeper review.

[teknium1]

Current main migrated this adapter to plugins/platforms/slack/adapter.py in 5600105478ffde29d7566b45421b100eaa29c4ef, so this hunk will not reach the active Slack runtime. Port the normalization there and apply it to the mention-stripped raw text rather than post-block-augmentation text.

[teknium1]

Closing as superseded by #69479 (merged): duplicate of #30592's re-normalization approach and targeted the pre-plugin-migration file.

Thanks for the work — it's credited in #69479's summary.