Tests against lost bytes in dense frames

- test_nano: every hex digit of B data is one drawDots() call, never single
  drawPixel() calls (the slow path that broke dense images in 2.19.2)
- tools/display_smoke_test.py: all yellow, a dense image and a checkerboard
  in live mode on the real display; fails on any frame check problem (wrong
  image, no answer, Nano restart, ERR reply)

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

CLAUDE.md

@@ -74,7 +74,11 @@ See README.md for the overview.
   `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).
+  clock in the tests doesn't count CPU time); `test_nano` only checks that each digit is
+  one `drawDots()` call. After flashing Nano or driver changes, run
+  `python tools/display_smoke_test.py` (asks the user first: it flips the dots for about
+  20 s): all yellow, a dense image and a checkerboard in live mode, fails on any frame
+  check problem.
 - 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