feat: send audio as native WeChat voice bubbles

[kenhuangus]

Summary

• Send audio/* as a native WeChat voice bubble: ffmpeg + silk-wasm to Tencent SILK_V3 (\x02#!SILK_V3), upload media_type=VOICE (4), send MessageItemType.VOICE (3).
• Outbound defaults match a real inbound personal-WeChat 语音条: encode_type=4, sample_rate=16000, no size, voice aes_key as base64(hex string) per parseAesKey, encrypt_type omitted.
• Native encode/upload/send failures fall back to FILE. asVoice / forceDocument honored.

Test plan

• npm test
• Live iLink: plugin-encoded MP3 and echo of Ken's inbound SILK both return sendVoiceMessageWeixin success
• Combined TEXT+VOICE in one item_list is rejected (invalid arguments); synthesized media.full_url CDN GET returns 400 (not shipped)
• Ken confirms a green 语音条 on personal WeChat

Related: #91, #215, #192. If the client still drops the bubble, that is the known iLink limitation; this PR still ships the native VOICE path plus FILE fallback.

[kenhuangus]

Live test notes (ken-mac, personal WeChat, plugin 2.4.8 + this branch)

What already works

• audio/* native path: ffmpeg 24 kHz WAV -> silk-wasm SILK_V3 (Tencent 0x02 prefix, 24 KB / 6120 ms) -> getuploadurl media_type=4 -> sendVoiceMessageWeixin encode_type=6 returned success.
• FILE attachments still deliver (control).
• getConfig + sendTyping still succeed on the same context_token after sendMessage starts failing.

What is not verified yet

• Personal WeChat client render of a green 语音条. Earlier iLink ret=0 with no bubble is 期待开放语音气泡消息 #91 / VOICE media/item can be accepted by API but does not render as a native WeChat voice bubble #215. Phone confirmation is still pending.

Send window

• After several outbound messages on one inbound turn, sendMessage returns ret=-2 errmsg=prepare failed until the user sends a new WeChat message. That blocked follow-up payload variants (encode_type=4 / 16 kHz inbound clone, echo of a real inbound SILK).

This branch also

• Always Tencent-prefixes outbound SILK (ensureTencentSilk).
• Downloads inbound VOICE even when voice_item.text transcription is present, and logs encode_type / sample_rate / magic bytes so we can echo a real client payload.

Will update this thread when a real-device 语音条 is confirmed or ruled out.

[kenhuangus]

Follow-up: default outbound native voice now matches a real inbound voice bubble from Ken's personal WeChat:

• sample_rate=16000
• encode_type=4 (client sends SILK bytes with type 4; proto comments saying 4=speex / 6=silk are not what the client emits)
• Tencent SILK prefix 0x02 #!SILK_V3

Live echo of Ken's own inbound SILK (6576 bytes, playtime 3637 ms) was sent as native VOICE at 23:40 ET, clientId openclaw-weixin:1788320467959-024de542. Waiting on phone confirmation that a green voice bar rendered above the [ECHO] marker.

[kenhuangus]

Live test update (Ken personal WeChat, iLink bot d2dabd8a1c40-im-bot):

Send	Codec	encode_type	sample_rate	API	Client (pending Ken)
23:06 native MP3->SILK	Tencent SILK 24 kB / 6120 ms	6	24000	sendVoiceMessageWeixin success	unconfirmed
23:40 ECHO of Ken inbound 语音条	same 6576-byte SILK Ken just sent	4	16000	VARIANT_OK ECHO	look above [ECHO]
23:47 plugin prepareOutboundVoice MP3	SILK 23338 B / 6120 ms	4	16000	success 1788320868133-3fd99ff1	look above [VOICE-16K]

The ECHO used Ken's exact inbound bytes (\x02#!SILK_V3, encode_type=4, 16 kHz). If that still has no green voice bar, this is the same iLink bot limitation as #91 / #215, not a missing SILK prefix or sample-rate mismatch.

Outbound defaults on this branch: 16 kHz + encode_type=4, FILE fallback if encode/upload/send fails. No gateway restart while a WeChat turn is in flight; live dist copied for the next process start.

[kenhuangus]

Follow-up live send: voice_item.size omitted (Ken inbound had size unset).

• Combined TEXT+VOICE in one item_list -> ret=-2 invalid arguments
• Voice-only, encode_type=4, 16 kHz, inbound SILK bytes, no size -> API success openclaw-weixin:1788321177032-d02b883d
• Marker: [VOICE-NOSIZE]

Please check whether a green voice bar is immediately above that marker.

[kenhuangus]

Follow-up: encode voice/image/video/file media.aes_key as base64(raw 16-byte key), not base64(utf8(hex)).

Live send of inbound SILK with corrected aes_key: look above [VOICE-AES].

[kenhuangus]

Follow-up: voice media.aes_key now matches inbound file/voice format (base64 of hex string, 44 chars). encrypt_type omitted on VOICE.

Live marker: [VOICE-HEX].

[kenhuangus]

Did not ship media.full_url: constructing download URL via buildCdnDownloadUrl on an outbound x-encrypted-param returns CDN 400. Reverted. Plugin remains at encode_type=4 / 16 kHz / no size / voice aes_key=base64(hex). Still waiting on phone confirmation of markers [VOICE-HEX] [VOICE-AES] [VOICE-NOSIZE] [VOICE-16K] [ECHO].

[kenhuangus]

Deep fix: OpenClaw sendMedia ctx field is audioAsVoice, not asVoice. Live agent TTS used asVoice=true with a .pcm and the plugin uploaded it as FILE (0-byte attachment). Plugin now reads audioAsVoice and treats pcm/aiff as audio.

[kenhuangus]

Next approach is protocol-level, not another SILK tweak.

Independent iLink SDKs (lith0924 Java SDK issue 11, 2026-07-02) report Tencent changed the protocol: bot-sent VOICE is accepted (ret=0) but personal WeChat no longer renders a bubble. Hermes and issue 215 show the same.

Remaining discriminators on this PR:

1. Replay inbound CDN refs (encrypt_query_param + aes_key the client already rendered) without re-upload. Dump of those refs is now env-gated in media-download + process-message.
2. Send the same VOICE item with message_type=USER instead of BOT. If the filter is on BOT+VOICE, USER may still render.

Also: OpenClaw sendMedia ctx field is audioAsVoice (not asVoice). Live TTS was uploading 0-byte .pcm as FILE.

[kenhuangus]

Outbound native VOICE is now disabled. sendWeixinMediaFile routes audio as FILE only.

[seaurching]

Same result here, reproducing with the official Tencent PR #9 implementation (direct MP3 upload as VOICE(4), encode_type=7, playtime = size/160).

We patched the exact PR #9 code into the plugin dist and sent 6 live voice messages to a real personal-WeChat account via a scanned iLink bot session: SILK encode_type=6/24 kHz, 5/8 kHz, and MP3 7/as-is, with playtime as real ms and as size/160. Every attempt: getUploadUrl(media_type=4) → CDN PUT → sendMessage(type=3) returned success, yet the client rendered nothing (silent drop). Text ✅, FILE(4)+FILE(4) MP3 attachment ✅, and the VOICE CDN upload ✅ all work on the same account — only the VOICE item vanishes.

Also ruled out: playtime unit (both real-ms and size/160 accepted, neither rendered) and SILK validity (our silk-wasm output decodes fine with kn007 silk-v3-decoder).

Detailed matrix: #215 (comment)

This includes the official PR #9 path, not just community guesses — I'd also like confirmation from the team whether outbound VOICE is supported for normal iLink bot accounts, or should be documented as unsupported.