Implement optional AES-CCM support for channels

[weebl2000]

Currently, messages to channels are only encrypted using AES-CTR. This ensures nobody can read your messages. However, people can still modify your messages because there is no way of knowing if the content being sent was what was originally sent. Let me give an example with rot13 encryption. In rot 13, 'abc' transforms to 'nop', but there is no way of knowing an attacker has maybe modified the original message to be adc, which would still perfectly well translate to 'nqp'. As long as the protobuf parsing goes well, we do not know if messages are modified. There was already AES-CCM support for private messaging, it adds a tag to the message that makes sure messages aren't altered without knowing the key.

This commit adds support for AES-CCM at the channel level, it will need everyone in the channel to agree on using it though, so it's disabled by default. This change will need app level support before being practically used by users.

supersedes #9602

Details:

• Reuses existing AES-CCM (aes_ccm_ae/aes_ccm_ad) — no new cipher added, same one used for private messaging
• 8-byte authentication tag — matches DM tag size
• Per-channel runtime boolean (aead_enabled in ChannelSettings) — no recompilation needed, configurable per channel from the app
• No silent fallback — returns TOO_LARGE error if payload + 8-byte tag exceeds LoRa max; AEAD channels reject packets that fail tag verification
• backwards compatible — disabled by default, nothing changes if you do not enable this
• max payload reduces from 239 to 231 bytes when enabled on a channel

What needs to happen upstream

• Proto file in meshtastic/protobufs needs the matching bool aead_enabled = 8 field added to ChannelSettings
• Client apps need UI support to toggle the setting per channel

[jp-bennett]

This looks like good work, but the approach we're planning to take is opt-in XEdDSA message signing as per #7602