feat: DingTalk stream immediate ACK + message_id dedup

[nap-liu]

Summary

• Immediate ACK: fire-and-forget dispatch, no longer blocks stream handler for 120s
• Message dedup: Redis SETNX (5min TTL) + in-memory fallback with periodic cleanup
• Prevents DingTalk timeout retransmission causing duplicate processing

Test plan

• DingTalk E2E: no duplicate messages observed in logs

[nap-liu]

Pushed fixes addressing both concerns from #371.

Concern 1 — dedup retry-safety (CRITICAL): 4e0b2dd rewrites the dedup model from a single marker into a processing / done state machine. The marker now flips to done only after the message is durably accepted (DB write + LLM dispatch). Failures revert to processing so DingTalk retries are processed normally instead of being silently skipped. 48a489f adds exception logging in the fire-and-forget wrapper so future failures surface in logs.

Secondary — API call rate: 22707a7 caches access_token and user_detail results via a new TTLCache helper (8f801e3) with single-flight to coalesce concurrent lookups. 74098dd is a follow-up that avoids caching empty user_detail responses (which would otherwise cache a transient miss for the full TTL).

Tests: test_dingtalk_dedup.py covers the new state transitions; test_dingtalk_service_cache.py covers cache hit/miss/single-flight behavior.

Could you take another look?