fix: size GCM tag buffer to the 16 bytes the SDK writes

[odudex]

gcm_get_tag() drains 4 hardware registers into the caller's buffer and reads them back through a uint32_t* cast, but aes.h documents a 4 byte buffer. AES_run() followed the header, so every GCM encrypt and decrypt wrote 12 bytes past the end of a stack array.

Widen the local to 16 bytes with 4 byte alignment, and copy using sizeof(self->gcm_tag) so the struct field stays 4 bytes. digest() and verify() return the same bytes as before, so existing KEF envelopes are unaffected.

Document why mac_len stays pinned at 4, since the SDK header still claims a 4 byte tag buffer and the upper 12 tag bytes are unverified.

[jdlcdl]

I've previously tested this on the Amigo, connected to debug the device itself and watching for more than 4 bytes from get_gcm_tag() (during both encryption and after decryption during authentication), but never saw anything more than 4 bytes returned on AES GCM ops. I DO recall that "not getting more than 4 bytes of GCM auth-tag" was an observation in krux's mid-2025 exploration to support GCM mode-of-operation.

[jdlcdl]

Noting that I'd like to play with altering the gcm_tag from 4 to 16 bytes:

• at line 64 where uint8_t gcm_tag[4]; to become uint8_t gcm_tag[16];...

• I believe it's working, I am seeing more bytes but they'd need to be verified against other aes-gcm implementations (easiest way is to add a 16byte auth GCM version to test). actually gcm_len is hard-coded/not-variable 0-16 in the MaixPy library so would need more work there.

• It would also require how kef.py's Cipher.authenticate() checks because we can no longer call aes_object.verify(auth), must compare truncated auth to match version, like: aes_object.digest[:abs(v_auth)] however Crypto.Cipher, used by simulator, raises if calling ".digest()" after decryption w/ "digest() cannot be called when decrypting or validating a message". may not need to do anything special in kef.py as long as when we create aes object that mac_len is respected and can truncate the internal tag to that length.

Otherwise, noting that this PR also is working for me, and could be merged with intent to follow up with later pr.