fix(discord): opt threaded free-response channels in

[voidberg-bot]

Summary

• preserve the existing inline default for Discord free_response_channels
• add discord.force_thread_channels / DISCORD_FORCE_THREAD_CHANNELS as an explicit opt-in for mention-free intake channels that should still auto-thread
• keep discord.no_thread_channels / DISCORD_NO_THREAD_CHANNELS as the stronger inline-reply opt-out
• document the new setting and cover YAML/env precedence plus routing behavior in tests

Test

• env -u DISCORD_ALLOWED_CHANNELS -u DISCORD_REQUIRE_MENTION -u DISCORD_FREE_RESPONSE_CHANNELS -u DISCORD_FORCE_THREAD_CHANNELS -u DISCORD_NO_THREAD_CHANNELS uv run --with pytest --with pytest-asyncio python -m pytest tests/gateway/test_discord_free_response.py tests/gateway/test_discord_channel_controls.py tests/e2e/test_discord_adapter.py -q -o addopts=
• uv run --with ruff ruff check plugins/platforms/discord/adapter.py tests/gateway/test_discord_free_response.py tests/e2e/test_discord_adapter.py tests/conftest.py tools/environments/local.py

[alt-glitch]

This was generated by AI during triage.

Duplicate of #33110 — same core mechanism (drop is_free_channel from skip_thread so free-response channels auto-thread, keeping DISCORD_NO_THREAD_CHANNELS as the opt-out). #33110 is the earliest still-open PR with that unconditional-decouple approach; this PR is a cleaner 2-file version of the same fix. This is a heavily saturated cluster (closed predecessors #12304/#26074/#31852). Note the competing alternative approach in #49726/#54285, which instead add an opt-in DISCORD_FORCE_THREAD_CHANNELS list rather than unconditionally decoupling — maintainer picks the approach.

[teknium1]

Thanks for the focused routing tests. The current-main premise is real: plugins/platforms/discord/adapter.py:6223 makes every free-response channel skip auto-threading.

Problems

• The proposed replacement changes the established default for every existing free-response channel. Current docs explicitly describe free-response as inline to keep a lightweight chat surface (website/docs/user-guide/messaging/discord.md:377) and state that free-response bypasses auto-threading (:385). This PR does not update that contract or provide an explicit migration/selection mechanism.
• This is not admission-only in operational effect: when auto-thread creation fails, the current thread-first path drops the request after sending an error (plugins/platforms/discord/adapter.py:6244-6263), whereas free-response channels currently remain inline.

Suggested changes

• Preserve the documented inline default and implement a config-backed opt-in for selected free-response channels if maintainers choose the dual-workflow design; retain no_thread_channels as the stronger opt-out.
• Include documentation and configuration/precedence tests with the selected API.

This is an automated hermes-sweeper review.

[teknium1]

This unconditionally changes the existing free-response contract, which current docs intentionally describe as inline to keep a lightweight chat surface (website/docs/user-guide/messaging/discord.md:377,385). Please preserve that default unless maintainers select the unconditional behavior; a config-backed opt-in would support threaded intake channels without changing every existing free-response channel.

[voidberg-bot]

Thanks — addressed in the latest push.

Changes from the original version:

• Preserves the documented free-response inline default.
• Adds discord.force_thread_channels / DISCORD_FORCE_THREAD_CHANNELS as the explicit opt-in for mention-free intake channels that should still auto-thread.
• Keeps discord.no_thread_channels as the stronger inline-reply opt-out when both are configured.
• Adds docs plus routing/config tests for default inline behavior, force-thread opt-in, YAML bridging, and no-thread precedence.

Local verification:

• 89 passed for the focused Discord gateway/e2e tests.
• ruff check passed on the touched Python files.