WeChat tracer: checked video intake and native video reply #907

Parent

#902 — Personal WeChat capability alignment. IM coordination reference: #48.

What to build

The owner can send a short video to the Bot, inspect or process its actual media in BotHarness, and receive a native video reply in the same WeChat DM.

Scope: personal WeChat/iLink, explicitly authorized paired-owner DM. Enterprise WeChat/WeCom is excluded.

Acceptance criteria

• Accept native video items through canonical Source Events and the checked media path. Preserve available duration, size and native source metadata; bound downloading, decryption and processing.
• Offer safe download and supported video presentation in source details. Only use a thumbnail when an actual qualified thumbnail is available.
• Expose video through existing compatible processing/model tools. State unavailable capabilities clearly and distinguish media access from model understanding.
• Implement the verified native video upload/send path with current own-identity authorization and trusted original DM routing. Record per-send outcomes honestly if accompanying text and media are separate native requests.
• Real E2E: Human sends a short uniquely identifiable clip; verify its real media content through a supported tool and receive a playable native video reply in WeChat. Independently check received content and relevant size/authorization failures.

Blocked by

• WeChat tracer: checked source file processing and original-DM file reply #903

Delivery and evidence

• Deliver one production-shaped tracer through the qualified Provider, canonical Messaging authority, applicable PersonaBot/Channel/Inbox behavior, and an operable Client path. Reuse the existing exclusive Consumer; do not create standalone dsh-im Sessions or a parallel message store.
• Keep the original external author, timestamp, lossless native message ID, Source Event ID, and trusted reply route. Every external send uses the acting Bot's own bound identity and current Grant; platform credentials, context tokens and media keys remain Provider-private.
• Qualify the changed Provider capability on the maintained fork and pin the verified artifact. Submit reusable Provider changes upstream where appropriate, without making upstream merge a release prerequisite.
• Complete fresh real WeChat E2E with the Human controlling WeChat. Include observable success and the relevant refusal/recovery behavior, focused regression coverage, and packaged-product verification. A model's claim, HTTP success, or client acknowledgement alone is not delivery/read proof.
• Preserve real screenshots or recording during acceptance; embed GitHub-renderable evidence in the PR, including before/after and applicable light/dark states for visible UI changes. Do not publish credentials or unrelated chat contents.
• Update the illustrated English and Chinese WeChat connection guide and reusable IM integration guidance with verified behavior and platform limitations; edit canonical source docs, not generated site content.
• Create one issue-linked PR, then pause for Human QA. Merge and deployment require their own Human authorization. Issue closure requires the accepted behavior, not only documentation or a capability flag.