WeChat tracer: native voice transcript intake and original-DM reply #905

Parent

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

What to build

When WeChat supplies text for a voice message, the PersonaBot receives that transcript with its voice provenance and can reply in the same DM.

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

Acceptance criteria

• Accept a valid owner voice item carrying a platform-provided transcript. Preserve the original voice item/source identity, available duration and transcript provenance rather than claiming BotHarness performed transcription.
• Render the transcript legibly in Inbox/source details with an explicit voice-message indication; do not invent an audio URL or playback affordance when audio has not been qualified.
• Feed the supplied transcript through canonical admission and the existing Wake/Orchestrator path, retaining deduplication, durable acceptance and the original authorized reply route.
• A voice item without a transcript must not appear as an empty successful transcription; clearly distinguish this from the separately scoped raw-audio capability.
• Real E2E: Human sends a voice message whose native event includes a transcript and a unique phrase; Bot responds based on that transcript in the original WeChat DM. Preserve original source and reply screenshots.

Blocked by

None — can start immediately. Completed prerequisite: #878 / PR #894.

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.