hermes - 💡(How to fix) Fix [Feature] Add text message debounce batching to WhatsApp and Weixin adapters

Problem

When users forward multiple messages or send rapid-fire text messages on WhatsApp or Weixin (WeChat), each message triggers the agent independently. This results in:

1. Wasted tokens — the agent processes N separate requests instead of one coherent request.
2. Fragmented responses — each message gets its own response, often repeating context or contradicting earlier replies.
3. Poor UX — the agent appears to "spam" responses to what the user intended as a single multi-part input.

This is especially visible when users forward a batch of messages (common on both WhatsApp and Weixin), where 5–20 messages arrive within seconds.

Existing Implementation

The Telegram adapter already solves this elegantly with a debounce-batching pattern:

• _text_batch_delay_seconds — initial quiet period before flushing (default 0.6s, env: HERMES_TELEGRAM_TEXT_BATCH_DELAY_SECONDS)
• _text_batch_split_delay_seconds — longer delay when a chunk is near the platform split threshold (default 2.0s, env: HERMES_TELEGRAM_TEXT_BATCH_SPLIT_DELAY_SECONDS)
• _enqueue_text_event() — buffers text events per session key, concatenates text, resets the flush timer
• _flush_text_batch() — waits for the quiet period, then dispatches the aggregated message to handle_message()

Source: gateway/platforms/telegram.py lines ~3396–3470

The key mechanism:

1. Incoming text events are keyed by session (chat + user + thread).
2. Subsequent events within the delay window get their text appended to the pending batch.
3. After the delay expires with no new events, the combined message is dispatched as a single handle_message() call.

Proposed Solution

Mirror the Telegram adapter's debounce-batching pattern for both the WhatsApp adapter (gateway/platforms/whatsapp.py) and the Weixin adapter (gateway/platforms/weixin.py).

For WhatsApp (WhatsAppAdapter)

Add to __init__():

• _text_batch_delay_seconds — configurable via WHATSAPP_TEXT_BATCH_DELAY_SECONDS (default: 0.8s)
• _pending_text_batches: Dict[str, MessageEvent]
• _pending_text_batch_tasks: Dict[str, asyncio.Task]

Add methods:

• _text_batch_key(event) — build session-scoped key from event.source
• _enqueue_text_event(event) — buffer and concatenate
• _flush_text_batch(key) — wait then dispatch

Modify _build_message_event() or _poll_messages() so that MessageType.TEXT events route through _enqueue_text_event() instead of directly calling handle_message().

For Weixin (WeixinAdapter)

Same pattern with Weixin-specific env vars:

• _text_batch_delay_seconds via WEIXIN_TEXT_BATCH_DELAY_SECONDS (default: 0.8s)
• Same _pending_text_batches / _pending_text_batch_tasks dicts
• Same _enqueue_text_event() / _flush_text_batch() methods

Modify _process_message() so text-only events (no media) route through the batching path.

Suggested Environment Variables

Set to 0 to disable batching (immediate dispatch, current behavior).

Design Notes

• The batch delay should be slightly longer for WhatsApp/Weixin than Telegram (0.8s vs 0.6s) because these platforms tend to deliver forwarded batches more spread out.
• Only MessageType.TEXT events should be batched. Media messages should continue to dispatch immediately.
• The existing Telegram _SPLIT_THRESHOLD adaptive delay logic is less relevant for WhatsApp/Weixin (they have different message size limits), but could be added later if needed.
• Consider extracting the batching logic into a shared mixin or helper in gateway/platforms/base.py or gateway/platforms/helpers.py to reduce duplication across all three adapters.

Impact

• Reduces token consumption when users send rapid-fire messages.
• Produces more coherent, single responses to multi-message inputs.
• Aligns WhatsApp and Weixin behavior with the already-batched Telegram experience.
• Fully backward-compatible when the delay defaults are conservative and can be set to 0 to opt out.