feat(ble): TX/RX fragment + byte counters in BLE heartbeat

Pre-this the 10s heartbeat reported running/scanning/connected/peers
state but nothing about whether data was actually flowing. With the
counters added to BLEInterface and threaded into the heartbeat
snprintf, the line now also surfaces:

  tx_pkt   — outbound RNS packets attempted
  tx_frag  — BLE fragments actually written/notified
  tx_b     — total bytes written
  tx_fail  — platform write/notify returned false
  rx_frag  — BLE fragments handed to the reassembler
  rx_b     — total bytes received

That was enough to root-cause the Columba-side stalls observed
during the BLE end-to-end testing session: pyxis showed connected=1
but tx_pkt frozen, surfacing that the keepalive loop wasn't firing
for a peer whose handshake had completed but identity recording
raced. Cumulative-since-start, no reset; cheap to keep on always.

lib/ble_interface/BLEInterface.h

@@ -281,6 +281,18 @@ private:
     PendingData _pending_data_pool[MAX_PENDING_DATA];
     size_t _pending_data_count = 0;
 
+    // Diagnostic counters — included in the periodic BLE heartbeat
+    // log so we can see "did fragments actually flow over a peer
+    // connection" without per-event logs flooding USB CDC. Cumulative
+    // since interface start.
+    uint32_t _stat_tx_packets = 0;     // outbound RNS packets attempted
+    uint32_t _stat_tx_fragments = 0;   // BLE fragments actually written/notified
+    uint32_t _stat_tx_bytes = 0;       // total bytes written
+    uint32_t _stat_tx_fail = 0;        // platform write/notify returned false
+    uint32_t _stat_rx_fragments = 0;   // BLE fragments handed to reassembler
+    uint32_t _stat_rx_bytes = 0;       // total bytes received
+    uint32_t _stat_rx_packets_complete = 0; // reassembled packets passed up
+
     // Thread safety for callbacks from BLE stack
     // Using recursive_mutex because handleIncomingData holds the lock while
     // calling processReceivedData, which can trigger onHandshakeComplete callback