WeChat tracer: checked raw voice access and supported audio processing #906

Parent

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

What to build

A voice message remains usable when WeChat does not provide a transcript: BotHarness can obtain the original audio and offer supported playback or processing through existing capabilities.

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

Acceptance criteria

• Extend checked source attachment reads to native voice media; preserve native codec, duration and sample-rate metadata when supplied, without inventing values.
• Decode only verified supported codecs into a usable bounded audio representation, or preserve a downloadable original with an explicit unsupported-codec result. Keep keys and private media references out of Client/model context.
• Provide an operable audio source detail/download path and playback where the format is supported. Reuse the existing processing/transcription capability when configured; do not add an unsolicited paid transcription service or treat access to bytes as understanding speech.
• A missing transcript, decode failure or unavailable transcription capability is visible and does not become fabricated transcript text. Text reply remains available through the original authorized DM.
• Real E2E: obtain fresh voice media, verify decoded audio by playback or an independently checked artifact, and exercise configured audio processing plus same-DM text reply. Demonstrate the path with native transcript use excluded from the processing proof.
• Native outgoing voice bubbles are not claimed by this ticket: qualify that separate server/codec contract before adding an implementation ticket. Sending an audio file must be labelled as file delivery, not native voice.

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.