Drop SPI clock to 10MHz, matching the proven-working driver

Fifth hardware run (after bracketing refresh with explicit power-on/off):
still solid black. Busy has now engaged and cleared at a normal duration
across every attempt regardless of what protocol-level sequencing changed,
which points away from the command sequence and toward something wrong
in what's actually landing in RAM.

GxEPD2's vendor source specifies 20MHz for this panel; the known-working
epaper_spi driver for this exact physical unit/wiring runs at 10MHz
instead. Untested until now - matching it, since 20MHz over real wiring
(not GxEPD2's reference breadboard) is a plausible source of corrupted
writes despite the controller still completing some waveform.

components/gxepd2/cycle_engine.h

@@ -10,8 +10,17 @@
 
 namespace esphome::gxepd2 {
 
+// GxEPD2's vendor source specifies 20MHz for this panel, but the
+// known-working epaper_spi driver for this exact physical unit/wiring
+// (waveshare-2.13in-bv4) deliberately runs at 10MHz. Busy consistently
+// engaging and clearing at a normal duration while content still comes out
+// wrong (solid black, then solid red, now solid black again) is consistent
+// with signal integrity problems at too aggressive a clock corrupting what
+// actually lands in RAM, even though the controller still completes some
+// waveform. Matching the proven-working clock instead of GxEPD2's generic
+// spec value.
 using EpdSPIDevice = spi::SPIDevice<spi::BIT_ORDER_MSB_FIRST, spi::CLOCK_POLARITY_LOW, spi::CLOCK_PHASE_LEADING,
-                                     spi::DATA_RATE_20MHZ>;
+                                     spi::DATA_RATE_10MHZ>;
 
 // Mechanically replicates one GxEPD2 driver's refresh cycle - reset pulse,
 // init command table, RAM-window set, per-plane byte burst, refresh