Fix solid-black output: correct the display-update-control bytes

Second hardware run confirmed the mechanical cycle itself is fine -
busy cleared naturally at ~16s (well inside the widened 60s ceiling),
so the earlier timeout was just too tight, not a real hang. But the
panel still came out solid black regardless of RAM content.

GxEPD2's vendor source sends {0x00, 0x80} to the display-update-control
register (0x21), but the known-working epaper_spi driver on this exact
panel/wiring sends {0x80, 0x80}. That register controls per-plane RAM
bypass options, so the wrong bypass bit would force a plane to a
constant value no matter what gets written to it - which is exactly
the symptom. Switching to {0x80, 0x80}.

components/gxepd2/panel_213_z98c.h

@@ -21,7 +21,15 @@ inline const uint8_t PANEL_213_Z98C_DRIVER_OUTPUT_CONTROL[] = {0xF9, 0x00, 0x00}
 inline const uint8_t PANEL_213_Z98C_DATA_ENTRY_MODE[] = {0x03};
 inline const uint8_t PANEL_213_Z98C_BORDER_WAVEFORM[] = {0x05};
 inline const uint8_t PANEL_213_Z98C_TEMP_SENSOR[] = {0x80};
-inline const uint8_t PANEL_213_Z98C_DISPLAY_UPDATE_CONTROL[] = {0x00, 0x80};
+// GxEPD2's vendor source sends {0x00, 0x80} here, but the whole panel came
+// out solid black regardless of RAM content with that value on real
+// hardware. The known-working epaper_spi driver on this exact same panel/
+// wiring (waveshare-2.13in-bv4, see device/epaper-nametag.yaml) sends
+// {0x80, 0x80} instead - this register controls per-plane RAM bypass
+// options, so a wrong bypass bit here would force a plane to a constant
+// value irrespective of what's actually written to it, matching the
+// symptom exactly.
+inline const uint8_t PANEL_213_Z98C_DISPLAY_UPDATE_CONTROL[] = {0x80, 0x80};
 
 inline const EpdCommand PANEL_213_Z98C_INIT[] = {
     {0x12, nullptr, 0, /*delay_before_ms=*/10, /*delay_after_ms=*/10, /*wait_busy_after=*/false},  // SWRESET