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.

Todo: retry same, re-confirm on device, at this commit height.