m9 and rng polishing

zephcore/boards/common/esp32_common.conf

@@ -60,8 +60,30 @@ CONFIG_BT_BUF_EVT_RX_COUNT=14
 CONFIG_ESP32_BT_CTLR_LE_SECURITY_ENABLE=y
 
 # ========== Heap ==========
-# ESP32 BLE stack requires larger heap (override zephcore_common 2KB default)
-CONFIG_HEAP_MEM_POOL_SIZE=32768
+# ESP32 BLE stack requires larger heap (override zephcore_common 2KB default).
+#
+# 32768 was NOT enough and failed non-obviously.  The Espressif controller
+# allocates its exchange memory through esp_bt_malloc_func(), which the Zephyr
+# port maps to k_malloc() (esp_heap_adapter.h, CONFIG_ESP_BT_HEAP_SYSTEM=y) —
+# i.e. straight out of this pool.  esp_bt_controller_init() asks for 0x7800 =
+# 30720 bytes in ONE allocation: 93.75% of a 32 KB pool, leaving 2 KB for block
+# overhead and every other k_malloc user that ran before bt_enable().  Boards
+# that allocated little before BLE init happened to fit; ThinkNode M9 (display +
+# colour overlay, STC8H keypad, LR1110) did not, and the blob asserted inside
+# its own allocator instead of returning ESP_ERR_NO_MEM:
+#
+#   BLE assert emi.c 164, param 00000000 00007800   <- (NULL, requested size)
+#
+# Zephyr's own driver anticipates this and prints "Consider increasing
+# CONFIG_HEAP_MEM_POOL_SIZE" (drivers/bluetooth/hci/hci_esp32.c) — but only on
+# the graceful path the blob does not take.  Every ESP32 board was one
+# allocation away from the same failure, so this is raised platform-wide.
+#
+# Headroom verified by build on all 12 shipped ESP32 boards: the S3/C3/C6 boards
+# have 66-135 KB free internal DRAM and absorb this easily.  ttgo_tbeam is the
+# sole exception (99.45% DRAM, 768 B free) and overrides it back in its
+# board.conf — see the note there.
+CONFIG_HEAP_MEM_POOL_SIZE=65536
 
 # ========== Flash ==========
 # 4MB is standard for XIAO/LilyGo RISC-V boards.