feat/dingtalk stream channel

[duguwanglong]

fix(channel/dingtalk): harden stream runner against silent stalls and inbound floods

Production triage of the DingTalk stream channel surfaced two P0
risks that would only fire under specific real-world conditions:

R1 — Silent stall (gateway rate-limit / region block / suspended app)
The dingtalk-stream SDK's start() swallows every error from
open_connection() and returns None instead of raising. When
the gateway accepts our ticket but immediately tears down the
websocket (e.g. risk-control trips, app suspended), the runner
burns one preflight + one reconnect cycle every ~2-60s forever
without surfacing any permanent error — the channel looks
"connected" while delivering zero messages.

R2 — Unbounded inbound concurrency (group bursts)
ChatbotHandler.process() previously dispatched each frame via
asyncio.create_task() with no cap. A noisy group flooding 100+
messages would spawn 100+ concurrent on_message coroutines, each
holding an LLM round-trip — easy path to OOM, rate-limit storms
on the upstream model API, and starvation of other accounts
sharing the event loop.

Fixes

• R1 — stall detection
  Track inbound delivery + per-run duration around every start()
  call. Treat "clean return + run < 30s + zero messages received"
  as a stall signal. After 5 consecutive short clean returns,
  raise the new DingTalkStreamStallError so the channel layer drops
  the account from the reconnect schedule (same path used today
  for permanent auth failures). Counter resets on the first
  healthy run so transient flakes can't accumulate strikes.

• R3 — bounded inbound dispatch
  Replace the ad-hoc create_task fan-out with a bounded
  asyncio.Queue (default 256) drained by a fixed worker pool
  (default 8). SDK process() uses put_nowait so the heartbeat
  ack path stays non-blocking; QueueFull drops the new message
  and bumps a counter for telemetry. Both sizes are tunable per
  account via dispatchWorkers / dispatchQueueSize.

  Counting _messages_received at enqueue time (before back-pressure)
  preserves the R1 stall signal even when shedding load — "gateway
  is pushing us things we can't handle" is NOT the same failure
  mode as "gateway has gone silent".

Refactor

• Introduce DingTalkPermanentError as the common base for
  non-retryable runner failures; DingTalkPermanentAuthError and the
  new DingTalkStreamStallError both inherit from it. channel.py's
  _classify_and_raise switches to the base class so future
  permanent error types are handled automatically.

Reliability bonus (P1.R4)

• Bound the synchronous client.close() teardown with a 5s
  asyncio.wait_for so a hung socket can't stall a channel restart
  indefinitely. Times out → log warning, proceed with cancel.