channels: add native media attachments and rich replies

[XnLemon]

Context

Follow-up to #77 / PR #97. The current channel implementation can safely normalize Telegram media/rich updates to text markers or captions, but it does not expose native attachments to Runner and outbound providers remain text-only.

Scope

Add protocol-neutral native media support without weakening the existing tenant, binding, idempotency, or Outbox boundaries.

Acceptance

• Extend the inbound contract with validated media attachments (image, video, audio, document) and provider metadata that does not expose secrets or untrusted fetch URLs to Runner.
• Telegram inbound media: preserve file identity/caption, perform bounded authenticated download through an owned client, enforce size/MIME limits, and persist or hand off through an explicit attachment storage boundary.
• WeCom inbound media: verify/decrypt supported media callbacks and normalize them into the same attachment contract; unsupported types remain fail-closed.
• Outbound providers can send supported media/rich replies through durable Outbox segments, with capability negotiation and deterministic text fallback when a destination cannot represent the event.
• Add attachment lifecycle, tenant isolation, replay/idempotency, cancellation, and cleanup semantics; do not log tokens, raw provider errors, or message payloads.
• Add deterministic fake-based unit/integration E2E and runnable examples; CI must not require production credentials or public provider endpoints.
• Update channel and deployment documentation with storage, limits, retention, and rollout guidance.

Non-goals

• OCR, ASR, video understanding, or model-specific multimodal inference.
• Live Telegram/WeCom/WeChat credentials in CI.
• Treating Public WeChat, WeChat customer service, and WeCom as interchangeable providers.

Related

• channels: extend Telegram and WeCom beyond direct text #77
• PR channels: extend Telegram and WeCom capabilities #97