Document the partial-refresh retry pattern in CLAUDE.md

Reflect the bumped 80ms tap-feedback delay and the 350ms retry that
catches HA state syncs landing in the e-paper's busy window.

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

CLAUDE.md

@@ -42,10 +42,19 @@ output (LOW silences it). No impact on UART download mode or OTA flashing.
 
 ## Display Refresh Pattern
 Two-tier refresh wired to `lvgl.on_draw_end` via two `mode: restart` scripts:
-- **Partial** (`refresh_display`, 60ms): calls `display_partial()` — fast 1-bit, non-blocking, immediate interaction feedback
+- **Partial** (`refresh_display`, 80ms then a 350ms retry): calls `display_partial()` — fast 1-bit, non-blocking, immediate interaction feedback
 - **Full** (`full_refresh_display`, 10s): calls `component.update: display0` → `display()` — full 2-bit grayscale quality restore after idle
 
-60ms was empirically tuned: 80ms felt sluggish, 40ms intermittently raced. `component.update: display0` only pushes the frame buffer to hardware and does not re-trigger `on_draw_end`.
+The retry exists because `display_partial()` silently drops calls when the
+e-paper is still busy from a previous refresh (`waveshare_epaper_2bit.cpp`
+~line 2003). Without it, HA-triggered widget updates (e.g. fan speed sync
+arriving 200-500ms after a tap) could land during the busy window of the
+tap's partial refresh and be lost until the 10s full refresh. The retry
+fires ~430ms after the last draw, by which point the e-paper's ~300ms
+partial cycle has cleared. `mode: restart` cancels the retry if a new
+draw arrives, so it only fires in the quiet period.
+
+`component.update: display0` only pushes the frame buffer to hardware and does not re-trigger `on_draw_end`.
 
 ## Grayscale Implementation
 Custom component model name: `2.90inv2-r2-2bpp`