[Feature]: recover WeCom AI Bot WebSocket channel as separate wecom_ws support

[Audacity88]

Summary

Recover the WeCom / WxWork AI Bot WebSocket long-connection channel work from #3305 as a separate wecom_ws channel, distinct from both the existing WeCom Bot Webhook channel and the WeChat personal iLink Bot channel.

Problem statement

ZeroClaw now has partial WeCom support:

• feat(channel): add WeCom Bot Webhook channel #3439 added wecom, the WeCom Bot Webhook channel. This is useful for outbound/send-only bot webhook delivery.
• [Feature]: Wecom(WxWork) channel support #3090 originally requested both webhook mode and WebSocket mode.
• feat(channel): add wecom_ws AI bot channel #3305 implemented a larger WeCom AI Bot WebSocket long-connection path as wecom_ws, but that PR was closed unmerged.
• feat(channel): recover WeChat iLink Bot channel from reverted PR #4221 #6130 is recovering the WeChat personal iLink Bot channel from feat(channel): add WeChat iLink Bot channel #4221. That is a different platform shape and should not be expanded to cover WeCom WebSocket support.

The remaining gap is native WeCom AI Bot WebSocket mode for inbound chat handling and active-session delivery.

Proposed solution

Port or reimplement the useful parts of #3305 against current master as a focused wecom_ws channel.

The recovered scope should include, if still appropriate:

• optional wecom_ws channel/config identity, separate from webhook-based wecom
• WebSocket long-connection runtime
• inbound chat handling
• progressive/streaming reply behavior
• allowlists for users/groups
• attachment download/decrypt handling
• proactive send support through the active connected channel session
• docs explaining the distinction between wecom webhook mode and wecom_ws AI Bot WebSocket mode

Non-goals / out of scope

• Do not fold this into the personal WeChat/iLink Bot recovery in feat(channel): recover WeChat iLink Bot channel from reverted PR #4221 #6130.
• Do not replace the existing wecom Bot Webhook channel from feat(channel): add WeCom Bot Webhook channel #3439.
• Do not redesign channel routing beyond what is needed for WeCom WebSocket support.

Alternatives considered

Keep #3090 as the only tracker. That works, but a separate issue is clearer because #3090 now covers both an already-landed webhook path and a remaining WebSocket path.

Acceptance criteria

• wecom webhook support remains unchanged.
• A distinct wecom_ws channel can receive inbound WeCom AI Bot WebSocket messages.
• The channel can send replies through the active WebSocket session.
• Access control is documented and covered by tests.
• Docs clearly distinguish WeCom Bot Webhook, WeCom AI Bot WebSocket, and WeChat personal iLink Bot.

Architecture impact

crates/zeroclaw-channels/, crates/zeroclaw-config/, channel orchestrator wiring, docs, and possibly scheduler/proactive delivery plumbing.

Risk and rollback

Medium. This adds a new optional enterprise channel with WebSocket traffic, credentials/secrets, attachment handling, and active-session delivery behavior. Rollback should be removing/disabling [channels.wecom_ws] or reverting the feature PR.

Breaking change?

No

Data hygiene checks

• I removed personal/sensitive data from examples, payloads, and logs.
• I used neutral, project-focused wording and placeholders.