fix: guard findChannelIdx == -1 + scope trail_units reset

C1/C2: onChannelMessageRecv and onChannelDataRecv both passed
findChannelIdx() through (uint8_t), so an unknown-secret packet
turned -1 into 255 and the message flowed into the offline queue,
UI history, notification and bot reply with a bogus channel index.
Drop such packets at the recv path; also harden addChannelMsg with
an MAX_GROUP_CHANNELS bounds check so a future caller can't poison
the channel-history ring buffer either.

H4: loadPrefsInt always reset trail_units_idx on sentinel mismatch,
even for jumps where the field was saved correctly (e.g. 0xC0DE0004
→ 0xC0DE0005). Scope the reset to sentinel == 0xC0DE0003, which is
the only case where the byte at that offset is actually the stale
sentinel low byte.

FEATURES.md: mark these three items as ✅ in the audit backlog.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

examples/companion_radio/DataStore.cpp

@@ -333,9 +333,13 @@ void DataStore::loadPrefsInt(const char *filename, NodePrefs& _prefs, double& no
       _prefs.home_pages_mask |= NodePrefs::HP_FAVOURITES;
     }
     // 0xC0DE0003 → 0xC0DE0004: trail_units_idx added after trail_min_delta_idx.
-    // Saves from 0xC0DE0003 have the sentinel bytes where trail_units_idx sits,
-    // so rd() picks up 0x03 (low byte of the old sentinel) — reset to default 0.
-    _prefs.trail_units_idx = 0;
+    // On a 0xC0DE0003 file the sentinel bytes sit where trail_units_idx is now,
+    // so rd() picks up 0x03 (low byte of the old sentinel) — reset just that
+    // case to default 0. Newer mismatches (e.g. 0xC0DE0004 → 0xC0DE0005) had
+    // the field saved correctly and must not be clobbered.
+    if (sentinel == 0xC0DE0003) {
+      _prefs.trail_units_idx = 0;
+    }
   }
 
   file.close();