Fix dense images on the Nano and the off image in slow mode

- Nano: B data is drawn fast enough for the serial line. A hex digit arrives
  every 87 us; with a division and four drawPixel() calls per digit a lit
  digit took about 105 us, so dense frames (all yellow, the panda bitmap)
  overflowed the 64 byte receive buffer: frames not shown or wrong, "Line
  too long", frame check repairs that failed the same way. Now the parser
  counts columns and rows and BROSE9323::drawDots() sets the 4 dots
  (about 20 us).
- ESP32: Power off and the start of the night draw the off image also when
  slow mode had the power off already (it powers on for it, once)
- Tests: drawDots() against drawPixel(), off image in slow mode
- Version 2.19.3

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

CLAUDE.md

@@ -69,6 +69,12 @@ See README.md for the overview.
   longer than about 5 ms overflows the 64-byte serial receive buffer; lost bytes shift the
   rest of a bitmap. That was the "picture moved up" bug. `test_driver` checks the time per
   `update()` call with a simulated panel.
+- The `B` data path must also keep up with the line: a hex digit arrives every 87 µs.
+  `_bitmapData()` counts columns and rows (no divisions) and sets each digit's 4 dots with
+  `BROSE9323::drawDots()`. With `p % w`, `p / w` and four `drawPixel()` calls it took about
+  105 µs per `F`, so dense images (all yellow, a full picture) lost bytes ("Line too long",
+  frame check mismatches). Check new per-character work with `avr-objdump` (the mock
+  clock in the tests doesn't count CPU time).
 - Flip time is stored in EEPROM as a magic word at address 0 and a `uint16_t` at
   address 2. Values outside 50–2000 µs are rejected.
 - The Nano replies `READY` (at boot), `ERR: ...` and `C xxxx` (checksum of its image, for