Fix: Treat all-zero channel secrets as empty/deleted slots instead of valid channel keys

[burningtree]

Summary

Treat all-zero channel secrets as empty or deleted slots instead of valid channel keys.

This PR was prompted after multiple users reported receiving unexpected group messages on channel they had never configured. Depending on the client, these messages appeared only in the RX log, as an unnamed channel, or as #unknown (also in meshcore-cli).

Clients represent channel removal by writing an empty channel record with a 32-byte zero secret. Previously, such a slot could still be interpreted as a valid 128-bit channel: the firmware would hash the first 16 zero bytes, producing channel hash 0x37.

Because empty slots were still considered during channel lookup, packets created with the publicly known zero key could be decrypted and handled like normal group messages. This could cause unsolicited messages to appear in connected clients under an empty or unknown channel and enter the regular message notification flow.

Changes

• Add a shared 32-byte zero-secret constant.
• Skip zero-secret slots in searchChannelsByHash().
• Treat a zero secret passed to setChannel() as channel deletion and clear the slot.
• Prevent zero-secret channels and empty slots from matching in findChannelIdx().

Result

Empty and deleted channel slots are now consistently treated as inactive. They no longer participate in channel lookup or decryption, preventing zero-key group messages from reaching connected Companion clients.

---

Cases

Shared key: 00000000000000000000000000000000
Example packet: 154535 B9 56 8F 05 60 10 0A B1 B537 7F 9A 2F 24 96 7F 45 5A C9 B5 4A 6C 12 E0 14 0F B7 B5 67 33 69 6D 37 64 A0 ED 9E A4 B4 50 A2 54 82 E7 (analyzer)