Display Fix for different versions of TBeam Supreme

[markmcgookin]

Original Problem:
A new LilyGo T-Beam Supreme with a functioning display (in terms of hardware) would not show any output on the screen when flashed with MeshCore firmware. LilyGo Hardware check firmware shows that the display does function normally.

NOTE:
While I had this issue, I pointed Claude Code at both the MeshCore repo and the LilyGo repo to diagnose and solve the issue. I understand if we do not like AI generated code in here, but this has solved my issue, and should work for other users/devices. Feel free to close if not appropriate.

Claude Code Explanation:
Found it. The V3.1 schematic has explicit notes in the OLED Display section:

▎ Slave 7 bit address definition:
▎ VHF: R52=0R R51=NC → 0x3C
▎ UHF: R52=NC R51=0R → 0x3D

The OLED's I²C address is selected by solder resistors (R51/R52) on the OLED daughter‑board, and LilyGo uses
different addresses for VHF vs UHF variants of the T‑Beam S3 Supreme V3.1.

Root cause

src/helpers/ui/SH1106Display.h:14 hard‑codes DISPLAY_ADDRESS 0x3C, and SH1106Display::begin() only ever talks to that
address. On a UHF/V3.1 board where the OLED is at 0x3D, the I²C write fails silently and the display stays dark —
even though Wire, power (ALDO1), and the SH1106 controller itself are all fine. The display is on Wire (GPIO 17/18)
and Wire.begin(PIN_BOARD_SDA, PIN_BOARD_SCL) is called correctly by ESP32Board::begin(), so the bus is up — it's just
being addressed at the wrong slave.

LilyGo's hardware test firmware works on the same board because examples/Factory/LoRaBoards.cpp scans the bus and
accepts the OLED at either 0x3C or 0x3D (LoRaBoards.cpp:1015‑1028, plus the default display_address = 0x3c; // It
might be 0x3D comment at line 51).

Why one device works and one doesn't

Your two "identical" Supremes are almost certainly different sub‑variants (likely V3.0 vs V3.1, or VHF vs UHF V3.1) —
the OLED daughter‑boards have different solder‑bridge configurations. The MeshCore firmware happens to work on the
0x3C unit and fails on the 0x3D unit.

Solution:

src/helpers/ui/SH1106Display.cpp — one change: begin() now probes 0x3C and 0x3D, reads register 0x00 at each, and
skips any candidate that returns 0x80 (the QMC6310N magnetometer's chip ID). Whichever address remains is the OLED.
What was actually wrong: the I²C scan on the affected board showed devices at both 0x3C and 0x3D — the OLED was at
one, a QMC6310N magnetometer was at the other. My first patch just took the first one that ACK'd, which happened to
be the magnetometer; writing SH1106 init commands at it did nothing visible. LilyGo's factory firmware avoids this by
checking the magnetometer's chip‑ID register before deciding which is the display.