fix: SM2135EH-Weissreste beim Wechsel zurueck auf Farbe loeschen

Der RGB-Zweig von nl_sm2135eh_set() schrieb Stromregister, Kanalbyte und
die drei RGB-Werte, liess SM_ADDR_WY (0xC5) aber unangetastet. Der Chip
behielt die zuletzt gesetzte Weiss-Mischung, und beim direkten Wechsel
Weiss -> Farbe (ohne Zwischenschritt ueber dunkel) schaelte sich der
Weissanteil beim Ausblenden der Farbe wieder frei - an einer migrierten
GU10 RGB gemessen.

Das ist dieselbe Klasse Fehler wie in 00d5a4c fuer die Gegenrichtung
behoben (WY-Zweig schrieb nie die RGB-Register), nur bislang unentdeckt
in dieser Richtung. Der RGB-Zweig schreibt jetzt zusaetzlich WY mit
0/0 - ein zweiter Bus-Transfer pro Aktualisierung, symmetrisch zum
WY-Zweig, der ebenfalls zwei Transfers braucht.

src/drivers/nl_sm2135eh.c

@@ -87,6 +87,15 @@ void nl_sm2135eh_set(const uint8_t ch[NL_CH_COUNT])
         uint8_t chan = dark ? SM_CHANNEL_STBY : 0x00u;
         uint8_t d[6] = {SM_ADDR_CURRENT, s_current, chan, ch[NL_CH_B], ch[NL_CH_G], ch[NL_CH_R]};
         sm_send(d, 6);
+        /* The WY data registers are cleared here too, even though this is the RGB branch:
+           the chip keeps whatever white value was last written, and a direct white -> colour
+           change never passes through the all-dark frame above. The stale white then bleeds
+           through as soon as the colour dims - the same defect as the colour -> white case
+           below (fixed in 00d5a4c, 2026-09-13), just mirrored: that fix made the WY branch
+           also write the (always-zero) RGB registers, this makes the RGB branch also write
+           the (always-zero) WY registers. Both directions had it; only one was caught first. */
+        uint8_t w[3] = {SM_ADDR_WY, 0, 0};
+        sm_send(w, 3);
     } else {
         /* The RGB data registers are written along with the channel select, even though they
            are always zero here: the chip keeps whatever colour was last written, and a direct