fix(slack): scope Socket Mode app token per profile

[kohoj]

Problem

Fixes #59739.

In multiplex gateway mode, each profile gets its own secret scope, but the Slack adapter still read SLACK_APP_TOKEN from process os.environ when opening Socket Mode. That lets secondary profiles authenticate their websocket with the default profile's app-level token while their bot token is correctly profile-scoped, so the adapter logs as connected but Slack delivers the secondary app's events to no gateway connection.

Root Cause

SlackAdapter.connect() used the scoped PlatformConfig.token for the bot token but bypassed agent.secret_scope for the app token:

app_token = os.getenv("SLACK_APP_TOKEN")

In a multiplexer, process env can hold another profile's secrets by design, and _profile_runtime_scope() installs the active profile's .env into get_secret() instead.

Fix

Resolve the Socket Mode app token through get_secret("SLACK_APP_TOKEN"). This preserves legacy single-profile behavior because get_secret() falls back to os.environ when multiplexing is inactive, while making the active profile scope authoritative when multiplexing is on.

Tests

• scripts/run_tests.sh tests/gateway/test_slack.py -q
• $HOME/.hermes/hermes-agent/venv/bin/python -m ruff check plugins/platforms/slack/adapter.py tests/gateway/test_slack.py

[teknium1]

Merged via PR #65629 — your commit was cherry-picked onto current main with your authorship preserved in git log (rebase merge). Your scope-authoritative get_secret("SLACK_APP_TOKEN") semantics were the right call (the competing or os.getenv variant reintroduced the cross-profile leak); we added a narrow UnscopedSecretError → env fallback on top so the default-profile startup loop and background reconnect rebuild (which call connect() unscoped under multiplex) don't fail-loop, plus a regression test for that path. Closes the #59739 report. Thanks!