openclaw - 💡(How to fix) Fix Feature: 抽象跨频道流式输出能力，支持 Telegram/Feishu 并方便扩展

Context

Lukin wants native-ish streaming output later as Phase 2, but it must be designed as a channel-extensible abstraction rather than a hard-coded Telegram or Feishu implementation.

Phase 1 is only the typing/working indicator. This issue tracks Phase 2: streaming / progressive output across channels.

Code Scan Notes

Current code already has channel-specific pieces, but they are not obviously unified as a clean extension point:

• src/plugin-sdk/channel-streaming.ts exposes config helpers for streaming, chunkMode, preview.chunk, nativeStreaming, and legacy fields
• src/channels/draft-stream-controls.ts has generic finalizable draft stream lifecycle helpers
• extensions/telegram/src/draft-stream.ts implements Telegram draft/message preview streaming
• extensions/feishu/src/streaming-card.ts implements Feishu Card Kit streaming sessions
• extensions/feishu/src/reply-dispatcher.ts contains Feishu-specific streaming lifecycle logic
• extensions/discord/src/draft-stream.ts, extensions/slack/src/draft-stream.ts, and extensions/matrix/src/matrix/draft-stream.ts suggest the pattern is already spreading per-channel

Proposal

Introduce/finish a channel-neutral streaming output abstraction so OpenClaw can progressively render assistant output through different channel adapters.

The abstraction should support:

• Telegram via draft preview or message/edit fallback
• Feishu via Card Kit streaming card or documented fallback
• Future channels through a small adapter contract, not copy-pasted dispatcher logic

Acceptance Criteria

• Define a stable channel streaming adapter contract in plugin SDK, covering start/update/finalize/discard/cleanup
• The contract supports both cumulative snapshots and token/delta updates
• The contract supports channel-specific transport capabilities: native streaming, draft preview, edit-message preview, card streaming, or fallback text
• Telegram and Feishu are implemented through the same abstraction layer, even if their transport internals differ
• Config remains channel-extensible, e.g. channels.<channel>.streaming.*, without hard-coding Telegram/Feishu-only fields into generic code
• Streaming can be disabled independently from typing indicators
• Errors degrade cleanly to final non-streaming delivery without duplicate visible messages
• Tests include at least one fake channel adapter plus Telegram and Feishu regression coverage

Non-goals For This Issue

• Do not block the Phase 1 typing indicator work on this.
• Do not require every channel to support streaming immediately.
• Do not expose raw model streaming directly to users without channel throttling/coalescing.

Implementation Notes

• Keep sensitive/tool-only/internal events out of visible stream unless explicitly designed for that channel.
• The adapter should make rate limits and cleanup explicit; streaming previews that spam messages are worse than no streaming.
• The existing Feishu and Telegram implementations can be used as reference adapters, but the final design should make adding a new channel straightforward.