gxepd2: raise WRITE_PLANE byte budget to cut loop-scheduling overhead

BYTE_BUDGET of 64 bytes/step made a 426T82 full-plane write (48000
bytes) take ~12.7s, almost entirely loop() scheduling overhead rather
than SPI transfer time. Raised to 16384, cutting it to ~1.07s on
hardware.

components/gxepd2/cycle_engine.h

@@ -243,7 +243,21 @@ class CycleEngine {
   // bytes) from ever making one loop() tick run long, replacing the old
   // per-256-byte esp_task_wdt_reset()+delay(1) throttle with simply not
   // doing enough work in one call to need it.
-  static constexpr uint32_t BYTE_BUDGET = 64;
+  //
+  // 64 was overly conservative: at 20MHz SPI that's ~25us of actual bus
+  // time, so a 426T82 full-plane write (48000 bytes) was bottlenecked
+  // almost entirely on loop() scheduling overhead (~17ms/step observed),
+  // not SPI - ~12.7s for one plane. Raised to 16384 (up to ~25ms of
+  // blocking per step is fine here), cutting that to 3 steps instead of
+  // 750 - measured ~1.07s for the plane write on hardware. The remaining
+  // time is dominated by write_byte_()'s per-byte SPI enable()/disable()
+  // (ESP-IDF transaction setup/teardown, ~21.7us/byte vs ~0.4us raw
+  // transfer), which is intentionally NOT batched away: it lets other
+  // devices on a shared spi: bus interleave between our bytes instead of
+  // being locked out for the whole burst. 1s is well under half this
+  // panel's own multi-second refresh time anyway, so it wasn't worth
+  // trading that fairness for more throughput.
+  static constexpr uint32_t BYTE_BUDGET = 16384;
 
   void step_write_plane_() {
     if (this->cursor_ == 0) {