openclaw - 💡(How to fix) Fix [Bug] Discord replies silently dropped: composed in transcript, never delivered to Discord channel

Summary

Discord channel replies composed by the runtime are silently dropped — the assistant turn completes 'successfully' (transcript shows the message), but no message is actually delivered to the Discord channel. This appears to be the same underlying delivery bug as #80715 (Slack) but affecting Discord.

Environment

• OpenClaw: 2026.5.7 (eeef486)
• macOS (arm64)
• Discord plugin: @openclaw/discord (external npm package)
• Xiaomi MiMo v2.5 Pro (primary) / DeepSeek V4 Flash via OpenRouter (test)

Reproduction

1. User sends a message in a Discord guild channel with @mention
2. Discord gateway receives the message (typing indicator appears)
3. Embedded agent session is created and processes the message
4. Assistant response is composed and appears in the session transcript with stopReason: 'stop'
5. No message is delivered to Discord — no error logged, no retry

Evidence

Session transcript (56ee5601-f96a-418d-97fc-27a004efd103.jsonl) shows the response was composed:

User: test
Assistant: Hey William 👋 Yeah I'm here. Test came through fine — Discord gateway's working. What's up?

Stop reason: 'stop', 26,624 total tokens consumed. No delivery error in gateway logs. Discord channel shows no message.

Additional Context

• This issue appeared after upgrading from 2026.3.24 to 2026.5.7
• The Discord plugin moved from built-in to external npm package (@openclaw/discord) in this version
• Config migration required adding plugins.entries.discord.enabled: true — without this, Discord doesn't start at all
• The channels.modelByChannel config is documented but not in the JSON schema, causing validation errors
• Same pattern as #80715 (Slack silent delivery drop) — likely shared delivery layer

Expected Behavior

Response should be delivered to the Discord channel after being composed.

Actual Behavior

Response is composed in transcript but never reaches Discord. No error logged.