Migre l'IHM OLED vers u8g2 (dashboard graphique, splash anime, economiseur d'ecran) et active la liaison TMS320 reelle

- TMS_DUMMY_MODE=false : reception/emission UART reelle avec le TMS320
  (au lieu de la simulation), echo debug optionnel sur Serial.
- Remplace le driver OLED maison (legacy/er_oled.*) par u8g2 : dashboard
  graphique avec bargraphs, icones d'alerte/danger, splash logo anime,
  economiseur d'ecran (balle rebondissante) qui se reactive sur activite
  HT ou consultation du dashboard web.
- Renomme le SSID WiFi en "HIVY", documente le protocole UART et les
  problemes d'affichage SSD1322/u8g2 rencontres (doc/OLED-u8g2.md).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

doc/OLED-u8g2.md

@@ -0,0 +1,66 @@
+# Ecran OLED : migration vers u8g2
+
+L'IHM OLED (`src/oled_ui.cpp`) utilise la librairie u8g2
+(`U8G2_SSD1322_NHD_256X64_F_4W_HW_SPI`) depuis la migration du driver
+maison (conserve dans `legacy/er_oled.cpp` / `legacy/er_oled.h` pour
+reference, non compile).
+
+## SPI matériel sur broches personnalisees
+
+Le SSD1322 est cable sur des broches qui ne sont pas les broches SPI
+par defaut de l'ESP32-C3. `SPI.begin(PIN_OLED_CLK, -1, PIN_OLED_MOSI,
+PIN_OLED_CS)` doit etre appele **avant** `u8g2.begin()` pour que le bus
+HW SPI d'u8g2 utilise ces broches (voir `OledUi::begin()`).
+
+## Registre remap (0xA0)
+
+Le remap par defaut d'u8g2 pour ce controleur (`0x06` dans
+`u8x8_d_ssd1322.c`) ne correspond pas au cablage de notre panneau
+(image en miroir horizontal). On reapplique apres `u8g2.begin()` la
+valeur validee sur l'ancien driver maison : `u8g2.sendF("caa", 0xA0,
+0x14, 0x11)` (COM remap + nibble remap actifs, column remap desactive).
+
+**Ne pas desactiver le nibble remap** (`0x10` au lieu de `0x14`) : deja
+teste, ca fait reapparaitre un miroir vertical et rend l'affichage
+illisible. u8g2 lui-meme active ce bit dans son propre remap par
+defaut (`0x06`), donc il est necessaire quelle que soit la config.
+
+## Logo splash coupe en deux moities (128px)
+
+Le logo de demarrage (256x64, dessine en un seul `drawXBMP`) s'affichait
+coupe en deux moities de 128px inversees, alors que le texte du
+dashboard (courtes sequences, meme chemin de dessin u8g2 sous-jacent)
+s'affichait correctement. Plusieurs hypotheses testees sur le hardware,
+**aucune n'a resolu le probleme individuellement** :
+
+1. Bit "nibble remap" du registre 0xA0 -- écarté (voir ci-dessus, a
+   empire le probleme).
+2. Optimisation RLE de `u8g2_DrawXBMP` (regroupe les runs de pixels en
+   longs segments qui traversent la frontiere interne a 128px du
+   SSD1322, puce a double controleur de colonnes) -- dessin pixel par
+   pixel teste, n'a pas resolu le probleme non plus.
+3. `u8g2_uint_t` tronque a 8 bits sur les largeurs >= 256 si
+   `U8G2_16BIT` n'est pas actif -- **verifie non applicable** : dans
+   u8g2 >= 2.36 (celle utilisee ici, voir `platformio.ini`),
+   `U8G2_16BIT` est defini inconditionnellement (fix upstream de
+   l'issue olikraus/u8g2#1222), confirme par un `static_assert(sizeof(
+   u8g2_uint_t) == 2)` qui compile sans erreur. Le flag `-D U8G2_16BIT`
+   est neanmoins ajoute en dur dans `platformio.ini` par precaution,
+   au cas ou une future version de la lib restreindrait a nouveau la
+   detection auto par architecture (ESP32-C3 = RISC-V, absent de la
+   liste `__arm__`/`__xtensa__`/... citee par cette issue).
+
+**Cause racine non identifiee formellement.** Contournement retenu :
+dessiner le logo en deux moities de 128px (`lebel_logo_left` /
+`lebel_logo_right` dans `src/lebel_logo_xbm.h`) via deux `drawXBMP`
+successifs (`OledUi::showSplash()`), aucun appel ne depassant alors la
+frontiere des 128px quelle que soit sa cause exacte. Le tableau
+`lebel_logo_bits` (image complete 256x64) reste dans le fichier a
+titre de reference mais n'est plus utilise et n'est pas garanti complet
+(voir taille reelle du tableau si besoin de le reactiver un jour).
+
+**A confirmer sur le hardware** : si le contournement en deux moities
+fonctionne, tant mieux. Si le probleme persiste malgre tout, la cause
+est ailleurs (registre remap plus subtil, alimentation, cablage) et il
+faudra reprendre l'investigation cote registre SSD1322 avec plus de
+prudence (deja regresse une fois en touchant ce registre a l'aveugle).