fix(dingtalk): serialize inbound messages per chat session

[spike2204]

Summary

When a user sends multiple messages rapidly (or sends text + file in quick succession), the adapter processes them concurrently, causing race conditions in AI Card lifecycle management — cards from message N clobber cards from message N+1.

Changes

• Add _enqueue_inbound() — per-chat asyncio.Queue with configurable max depth (default 32)
• Add _sweep_session_queues() — periodic cleanup of idle session queues (>30min)
• Route all _on_message() calls through the per-chat queue so messages within the same conversation are processed sequentially while different conversations remain concurrent

Related

Part of the DingTalk adapter enhancement series — see #12769 for the umbrella PR.

[teknium1]

Thanks for isolating the same-chat concurrency concern. The issue remains relevant on current main, but this implementation needs rework after the adapter migration.

Problems

• plugins/platforms/dingtalk/adapter.py:640 stores the latest inbound message per chat, while :863 reads that mutable value for AI Card routing. A second callback can overwrite it while the first turn is still running.
• The proposed chain would await _on_message(), but gateway/platforms/base.py:4779 starts _process_message_background() and returns. It therefore does not wait for the agent turn that performs card sends, so it cannot protect the mutable context above.
• The PR targets the removed gateway/platforms/dingtalk.py; current code lives in plugins/platforms/dingtalk/adapter.py after 5600105.

Suggested changes

• Rework the fix in the plugin adapter around turn-scoped card context or the BasePlatformAdapter session lifecycle, and add a two-message same-chat regression test that holds the first turn active.

Automated hermes-sweeper review.