M5 colors fixed: JPEG byte order + DPI memory layout

Two channel-swap bugs were stacked, hiding each other on symmetric
pixels (white text on black background) and showing up only on
saturated colour JPEGs:

  1. jpeg_decoder: rgb_order was JPEG_DEC_RGB_ELEMENT_ORDER_RGB which
     empirically emits the RGB565 word in big-endian byte order (the
     IDF header comment "color component in big endian" is correct;
     the enum's "RGB" name is misleading). Our painter reads native
     LE uint16_t, so the bytes were always swapped. Flipped to
     _BGR which emits LE — verified by dumping decoded bytes for
     solid red/green/blue JPEGs.

  2. display: rgb565_to_rgb888 wrote bytes [R, G, B], but the
     ESP32-P4 DSI engine + TC358762 + Pi panel expect [B, G, R]
     in memory despite the "RGB888" label. (MIPI DSI defines bit
     order, not byte position in memory.) Verified with an
     embedded solid-blue test JPEG: with [R, G, B] the panel
     showed solid red; with [B, G, R] it shows solid blue.

Diagnosed by embedding a 480x800 blue test JPEG in firmware, decoding
+ dumping the buffer at boot, and reading the actual bytes over USB
serial (ethernet was disconnected mid-investigation). The temporary
self-test + debug dump are removed; the fixes themselves are tiny.

0 files changed, 0 insertions, 0 deletions