Summary

Fix WeCom inbound media decryption when the message aeskey is sent as an unpadded Base64 string.

What changed

• Normalize inbound WeCom media aeskey before Base64 decoding
• Accept 43-character unpadded keys returned by WeCom media messages
• Add a regression test covering unpadded aeskey

Why

In real WeCom bot traffic, inbound image media could fail with:

Incorrect padding

The adapter was decoding aeskey with base64.b64decode(aes_key) directly. Some WeCom media messages provide the AES key in unpadded Base64 form, so decoding fails before AES-CBC decryption begins.

This patch pads the key to a multiple of 4 before decoding, matching the behavior used by other WeCom implementations.

Validation

Production validation:

• Verified against a real production failure where inbound WeCom image messages failed with Incorrect padding
• Confirmed the fix by successfully receiving, decrypting, caching, and analyzing a WeCom image after the change

Automated tests:

• ./.venv/bin/python -m pytest -q tests/gateway/test_wecom.py -k "decrypt_file_bytes" -> 2 passed
• ./.venv/bin/python -m pytest -q tests/gateway/test_wecom.py -> 41 passed