Fix Wisdom channel replies with polling fallback

[Germey]

Summary

Wisdom accepts WebSocket clients but currently never publishes message.new, while inbound messages are available through /api/messages/poll. This left coding-bridge channels start connected but unable to answer WeChat messages.

• run WAL-backed polling alongside the existing WebSocket receive loop
• preserve stable Msg_* conversation IDs for policy/session identity while using the display name only for Wisdom sends
• deduplicate messages observed through both WebSocket and polling
• overlap timestamp cursors, advance watermarks for already-seen rows, and back off transient polling failures
• page conversation metadata within Wisdom's legal offset <= 1000 range and fail closed on unknown conversation types
• add focused HTTP, cursor, pagination, identity, and polling regression coverage

Verification

• pytest -q tests/test_channels_wechat.py -> 30 passed
• Ruff check and format check -> passed
• live channels doctor -> token accepted
• live Claude turn through https://api.acedata.cloud -> succeeded
• live Wisdom send task -> succeeded
• broader channel run -> 138 passed; 5 pre-existing caplog capture failures when run together (expected records were emitted to stderr; representative test passes in isolation)

Known upstream limit

Wisdom /api/messages/poll returns the newest 500 rows and exposes no continuation cursor. A burst above 500 rows between polls cannot be recovered by the client. This change uses the maximum page size, one-second overlap, deduplication, and retry backoff; lossless high-volume recovery requires a future oldest-first/keyset Wisdom API.

对抗评审 (reviewer: claude-subagent, 3 rounds)

• RISK: same-second cursor could drop messages -> fixed with a one-second overlap and ID deduplication
• RISK: WS-seen rows did not advance the poll watermark -> fixed by deriving the watermark from all returned rows
• RISK: conversation pagination trusted an incorrect total -> fixed by short-page pagination within the API offset bound
• RISK: unknown conversation type could bypass group policy -> fixed by refusing untyped routes
• RISK: display names replaced stable conversation IDs -> fixed by separating policy/session identity from send_target
• RISK: pagination could exceed Wisdom's offset <= 1000 validation -> fixed by capping requests at the last legal page
• RISK: newest-first 500-row truncation -> not adopted locally because omitted rows never reach the client; documented above as an upstream API limitation

Automatic production E2E

Verified after the final fix with no manual dispatcher injection:

• inbound WeChat message reached Wisdom at 2026-07-21T10:38:57Z
• CodingBridge polling automatically started a Claude turn through AceDataCloud
• turn completed outcome=ok in 39.718s with a 747-character reply
• Wisdom recorded the outbound message in the same conversation at 2026-07-21T10:39:47Z
• corresponding Wisdom send task reached status=succeeded
• no channel send_failed or provider error was logged