Bug Description

When the agent calls clarify with multiple choices on Discord, the question is sent to the user but the clarify hangs indefinitely with ⏳ Still working... messages until the 10-minute timeout. The user's response is never intercepted.

Root Cause

tools/clarify_gateway.py:get_pending_for_session() (line 178) filters entries by awaiting_text=True. Choice-based clarifies are registered with awaiting_text=False (designed for Telegram's button path). On Discord, the base send_clarify renders choices as text, but the user's reply is never found by the intercept.

Steps to Reproduce

1. Run Hermes gateway with Discord platform
2. Send a message that triggers clarify with choices
3. Bot sends: "❓ Question?\n 1. Option A\n 2. Option B\n Reply with the number or text."
4. User replies: "1" or "Option A"
5. Clarify hangs: ⏳ Still working... (iteration 10/150, running: clarify)
6. Continues until 10-minute timeout

Expected Behavior

Clarify should be resolved immediately when the user responds, regardless of platform.

PoC

# Fresh Docker reproduction
docker run --rm ghcr.io/caixa-git/poc-clarify

PoC confirms:

• ✅ Bug reproduced: get_pending_for_session() returned None for choice-based clarify
• ✅ Fix verified: entry found after mark_awaiting_text()
• ✅ 41/41 clarify-related tests pass

Fix PR

PR #26008: #26008

Fix: Remove the awaiting_text filter from get_pending_for_session() so it returns the oldest pending clarify entry regardless of mode.

Affected Platforms

• Discord (no button support) — primary
• Slack (no button support)
• WhatsApp (no button support)
• Any platform using base send_clarify text fallback

Environment

• Hermes version: latest (main)
• Platform: Discord (also affects Slack, WhatsApp)
• OS: Linux (verified from fresh Docker install)