fix(gateway): prevent third-sender message drop in queue-mode debounce

[AhmetArif0]

Summary

• Bug: In busy_text_mode=queue (the default), messages from a third sender in a group chat are permanently and silently dropped when two prior senders have created a debounce/pending collision.
• Root cause: _queue_text_debounce hit an early return without saving the incoming event anywhere when (a) sender B's debounce state is stuck in the store (task=None, timer fired but couldn't flush because pending belongs to sender A) and (b) the new message from sender C can't merge with B's stuck state OR with pending-A.
• Fix: Remove the _can_merge(existing_pending, event) guard from the inner conflict branch and unconditionally call merge_pending_message_event — C's text is appended to the pending slot (or placed there directly if empty), matching the pre-debounce behaviour that always queued follow-ups regardless of sender.

Affected path

gateway/platforms/base.py → _queue_text_debounce(), the inner if state is not None and not self._can_merge_text_debounce_events(state.event, event): branch introduced in #31341.

Reproduction scenario

1. Agent is processing a session (active session lock held).
2. Sender A's message is debounced, timer fires, flushed to _pending_messages.
3. Sender B's message is debounced; timer fires but _flush_text_debounce_now returns False because pending-A is a different sender → B stuck in store with task=None, no retry scheduled.
4. Sender C (third distinct sender) arrives → _queue_text_debounce tries to flush B, fails again → hits return → C is never written to store, pending, or anywhere else.

Only affects multi-user group chats (Matrix, Slack channels, Discord servers, WeChat groups) with 3+ participants messaging simultaneously during an active session.

Changes

File	Change
gateway/platforms/base.py	Remove sender-check guard; always call merge_pending_message_event in the stuck-debounce fallback
tests/gateway/test_active_session_text_merge.py	Add test_third_sender_not_dropped_when_debounce_store_is_stuck regression test

Test plan

• New regression test test_third_sender_not_dropped_when_debounce_store_is_stuck pins the exact 3-sender scenario (A in pending, B stuck in store with task=None, C from third sender → C survives in _pending_messages)
• All 16 tests in test_active_session_text_merge.py pass
• test_busy_session_ack.py (16 tests), test_base_topic_sessions.py (10 tests), test_wecom.py (44 tests) — all pass, no regressions

[teknium1]

Thanks for tracing the shared-session collision; current main still has the early return at gateway/platforms/base.py:4262-4277, so the delivery-loss premise is valid for queue-mode shared sessions.

Problems

• The new unconditional merge at gateway/platforms/base.py:2830 appends C's text to the existing A event. merge_pending_message_event(..., merge_text=True) only updates existing.text (gateway/platforms/base.py:2137-2144), so C is processed under A's source. That conflicts with the existing separate-sender contract in tests/gateway/test_active_session_text_merge.py:245-271.
• The new test only checks that C text appears in the pending slot. It does not verify original event/source attribution or eventual separate delivery for B and C.

Suggested changes

• Preserve the events as separate queue entries instead of merging different senders. The runner's existing head-slot/overflow FIFO pattern is documented at gateway/run.py:4365-4425.
• Add a drain-path regression asserting A, B, and C are processed separately with their original sources.

Automated hermes-sweeper review.

[teknium1]

This merges C into A's existing MessageEvent. With merge_text=True, the helper only mutates existing.text and retains A's source (gateway/platforms/base.py:2137-2144), so C is misattributed. Please enqueue a distinct event instead of merging different senders.