v1.0.8: Fix heap exhaustion from unbounded random_blobs

Root cause: Python Reticulum trims random_blobs per destination entry
(MAX_RANDOM_BLOBS=64 in-memory, PERSIST_RANDOM_BLOBS=32 on disk).
The C++ firmware had these constants defined but NEVER enforced them,
causing unbounded growth. With 21 paths x 60+ blobs x ~90 bytes each,
the destination table alone consumed ~57KB of the ESP32 324KB heap.

Fixes:
- Trim random_blobs after insert (matching Python behavior)
- Trim random_blobs on deserialization from flash
- Trim random_blobs to PERSIST_RANDOM_BLOBS on serialization
- Enforce _path_table_maxpersist when writing path table (was declared
  but never used - write_path_table saved everything)
- Reduce MCU constants: MAX_RANDOM_BLOBS 64->16, PERSIST_RANDOM_BLOBS 32->8
- Reduce path_table_maxsize 128->24, maxpersist 32->12
- Add memory diagnostic after path table load
- Trim loaded paths to maxsize on startup via cull_path_table()

Results: destination_table 21KB->5.8KB, free heap 63K(22%)->156K(49%)

RNode_Firmware.ino

@@ -648,12 +648,11 @@ void setup() {
       // ── Boundary Mode: Load config and optionally set up WiFi + TCP ──
       HEAD("Boundary Mode: Initializing...", RNS::LOG_TRACE);
 
-      // With TLSF pool moved to PSRAM we have plenty of room.
-      // 128 path entries supports ~15-20 devices comfortably.
-      // cull_path_table() is patched to evict backbone paths first, preserving
-      // local (LoRa / local-TCP) paths needed for inbound message delivery.
-      RNS::Transport::path_table_maxsize(128);
-      RNS::Transport::path_table_maxpersist(32);
+      // ESP32 has only ~324KB heap. Each path entry with random_blobs costs
+      // ~200-500 bytes. Keep tables small to avoid heap exhaustion.
+      // cull_path_table() evicts backbone paths first, preserving local ones.
+      RNS::Transport::path_table_maxsize(24);
+      RNS::Transport::path_table_maxpersist(12);
       boundary_load_config();
 
       // Start WiFi if enabled