Fix 1-byte out-of-bounds read in receive() scan loop

[94xhn]

Bug

In BLEMIDI_Transport::receive(), the scan loop that advances rPtr past trailing data bytes checks the buffer content before checking the bounds:

while ((buffer[rPtr + 1] < MIDI_TYPE) && (rPtr < (length - 1)))
    rPtr++;

Because && is evaluated left-to-right, buffer[rPtr + 1] is read before rPtr < (length - 1) is checked. When rPtr reaches length - 1 and the final byte(s) are all data bytes (< MIDI_TYPE), this reads buffer[length], one byte past the end of the caller-supplied buffer.

This function is called from every hardware backend (BLEMIDI_ESP32.h, BLEMIDI_ESP32_NimBLE.h, BLEMIDI_Client_ESP32.h, BLEMIDI_ArduinoBLE.h, BLEMIDI_nRF52.h) with a buffer that comes directly off the BLE transport, so this is reachable from an ordinary MIDI message ending near the buffer boundary.

Fix

Swap the && operand order so the bounds check is evaluated first and short-circuits before the array index:

while ((rPtr < (length - 1)) && (buffer[rPtr + 1] < MIDI_TYPE))
    rPtr++;

No other logic changes. Verified against a real 5-byte NoteOn packet (0x80, 0x80, 0x90, 0x3C, 0x64) placed immediately before a guard page: the unmodified code reliably reads one byte past the buffer end, and the one-line fix eliminates the out-of-bounds access while parsing the same packet identically (mBleClass.add(0x90), add(0x3C), add(0x64)).

[lathoub]

Super nice catch @94xhn . Kudos!!
I happily accept the PR