fix(wecom): handle AI Bot file/image messages with AES decrypt and fallback

[kissdge]

Problem

WeCom AI Bot file/image messages were being silently dropped by Hermes Agent due to multiple bugs in gateway/platforms/wecom.py:

1. File messages without text body → skipped by if not text and not media_urls: return
2. AES key missing base64 padding → WeCom sends 43-char keys without =, causing b64decode failure
3. AES decryption had no fallback → failure silently returned None
4. image_keys not recognized → WeCom AI Bot specific image delivery mechanism ignored
5. media_id not supported → direct media download via API not implemented
6. Wrong encryption mode → Official docs say OFB, but WeCom actually uses AES-256-CBC + PKCS#7 padding

Fixes

Fix	Description
File placeholder text	Inject [收到文件消息] when file msg has no text body
AES key padding	Auto-append = padding for 43-char base64 keys
AES-256-CBC	Switched from OFB to CBC mode with PKCS#7 padding
response_url fallback	POST to response_url when AES decryption fails
image_keys support	Resolve via aibot_get_msg_media API
media_id download	Direct download via aibot/media/get API
Debug data	Save encrypted data + aeskey on failure for offline analysis
Debug logging	Comprehensive logging throughout media pipeline

Testing

• ✅ Excel file receive (21.6 KB .xlsx) — cached and readable via pandas
• ✅ Image receive — cached and analyzable via vision AI
• ✅ AES-256-CBC decryption working
• ✅ Debug fallback mechanism in place

Files Changed

• gateway/platforms/wecom.py (+229 / -18 lines)

References

• PR fix(wecom): handle AI Bot file messages with empty sender_id and AES decrypt #19121 — fix(wecom): handle AI Bot file messages with empty sender_id and AES decrypt
• PR fix(wecom): support aibot image pic_url and multiple AES key formats #17375 — fix(wecom): support aibot image pic_url and multiple AES key formats

[alt-glitch]

Significant overlap with #19121 (AI Bot file messages with empty sender_id and AES decrypt) and #14888 (pad base64 aeskey). The AES-256-CBC mode switch and response_url fallback are net-new, but the base64 padding and file placeholder fixes are duplicated across multiple open PRs.

[teknium1]

Thanks for investigating the WeCom AI Bot media path. The empty-message guard remains relevant, but this needs a targeted port and corrections before it can be salvaged.

Problems

• The new media_id downloader builds its payload with self.bot_id, while the active adapter stores the value as self._bot_id at plugins/platforms/wecom/adapter.py:156; no self.bot_id property exists. That path would raise before its try block.
• The decrypt-failure debug branch persists aeskey-derived diagnostics under a hard-coded ~/.hermes path. It should not write secret key material or bypass profile-scoped storage.
• The changed file was migrated to plugins/platforms/wecom/adapter.py by 5600105478ffde29d7566b45421b100eaa29c4ef. Current main already carries key padding/CBC at plugins/platforms/wecom/adapter.py:1069-1090 and appmsg attachment handling at :685-732; the net-new paths need tests in tests/gateway/test_wecom.py.

Suggested changes

• Port only the remaining behavior to the active plugin, use _bot_id, remove secret persistence, and add mocked coverage for placeholder dispatch, fallback, image keys, and media IDs.

Automated hermes-sweeper review.