Fix distorted animated icons on ESPHome 2026.4.0 (#331)

[weirded]

Fixes #331.

Root cause

ESPHome 2026.4.0 reworked ImageRGB565 in two ways that together break every RGB565-with-transparency icon produced by EHMTXv2:

1. Default byte order flipped from big-endian to little-endian for the Python encoder, but the C++ Image::get_rgb565_pixel_ decoder still reads big-endian. Every pixel comes out byte-swapped.
2. Alpha channel moved from per-pixel interleaved to an appended block via a new encoder.end_image() call. For multi-frame animations the new layout is actually broken end-to-end: write_image() calls end_image() per frame, each call appends the entire growing alpha buffer, and Animation::update_data_start_() advances data_start_ by only w*h*2 bytes (the RGB-only frame size). The decoder then reads "alpha" bytes that fall inside the next frame's RGB data — producing the pixel-soup reported in the issue.

Fix

Two small changes in components/ehmtxv2/__init__.py:

• Call encoder.set_big_endian(True) so RGB565 bytes match what the C++ decoder reads. Guarded with hasattr for backwards compatibility; no-op on older ESPHome where BE was already the default.
• Switch icon transparency from ALPHA_CHANNEL to CHROMA_KEY. Chroma-key stores the transparent-pixel marker (0x0020) inline in the RGB565 stream, so every frame is exactly w*h*2 bytes and Animation frame indexing works correctly on every ESPHome version. The only semantic change is that alpha values between 1 and 127 now render fully transparent instead of partially opaque — 8x8 pixel-art icons (LaMetric style) are binary-alpha in practice, so this matches real usage.

Testing

Verified locally on ESPHome 2026.4.0 against a physical Ulanzi display with both static and animated icons — previously distorted animations now render correctly. Byte-level verification of the encoder output confirms each frame is w*h*2 bytes and the chroma-key sentinel 0x0020 is placed at transparent pixels in big-endian form.

Compatibility

• ESPHome 2026.4.0+: fixes distorted icons.
• ESPHome 2025.10.x – 2026.3.x: unchanged output. set_big_endian(True) matches the old default; CHROMA_KEY worked identically here.
• ESPHome <2025.10: set_big_endian didn't exist yet; hasattr guard makes this a no-op and byte order defaulted to BE anyway.

Notes

• This PR targets dev-01. A cherry-pick onto 2025.12.0 is trivial (only this block is touched) if you'd like to ship a patch release for current stable users.
• No user-facing config change needed.