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/ESP32-UART.md

@@ -137,10 +137,22 @@ trame si ca ne correspond pas (trame corrompue).
   `updateSimulation()`, qui simule des valeurs realistes (utile comme
   reference de plage de valeurs attendues : `Vin` ~400V, `Iin` ~1.2A,
   `V1`/`Vout` ~200V, `I1`/`I2` ~2.5A, `T1`/`T2` ~40°C).
-- `include/config.h` : `TMS_DUMMY_MODE` (actuellement `true`) fait
-  tourner l'ESP32 sur la simulation interne au lieu de lire l'UART reel.
-  **A passer a `false` une fois le firmware TMS320 pret et teste**, pour
-  activer la reception reelle des trames `$T,...*XX`.
+- `include/config.h` : `TMS_DUMMY_MODE` (actuellement `false`, liaison
+  reelle active) fait tourner l'ESP32 sur la simulation interne au lieu
+  de lire l'UART reel quand mis a `true` (utile pour developper l'IHM
+  sans hardware TMS320 branche).
+
+## A faire cote protocole (pas encore implemente)
+
+- **Trame de defaut** : le TMS doit signaler lui-meme une coupure de
+  securite des sorties PWM (court-circuit, surintensite I1/I2,
+  temperature critique >80°C) — pas de champ dedie actuellement, la
+  telemetrie ne donne que les mesures brutes. Cote ESP32,
+  `OledUi::drawDashboard()` (`src/oled_ui.cpp`) affiche pour l'instant
+  DEFAUT simplement quand HT n'est pas commande (`!cmd.ht`), en attendant
+  cette trame. Quand elle existera, ajouter le champ correspondant dans
+  `Telemetry` (`include/protocol.h`) et brancher la vraie condition dans
+  `drawDashboard()`.
 
 ## Points de vigilance
 
@@ -149,7 +161,7 @@ trame si ca ne correspond pas (trame corrompue).
   pas d'erreur visible — la telemetrie n'avancera simplement pas).
 - Terminer chaque trame par `\n` uniquement (le `\r` est tolere/ignore
   cote ESP32 mais pas necessaire).
-- Ne pas depasser une longueur de ligne de 160 caracteres (buffer fixe
-  cote ESP32, `g_lineBuf[160]` dans `tms_link.cpp`).
+- Ne pas depasser une longueur de ligne de 200 caracteres (buffer fixe
+  cote ESP32, `g_lineBuf[200]` dans `tms_link.cpp`).
 - Verifier au multimetre/oscilloscope le niveau logique du TMS320 avant
   de le relier a l'ESP32-C3 (3,3V attendu).

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).