next iteration on display, still some artifacting issues, and ux with buttons states and updating

README.md

@@ -225,10 +225,14 @@ about PSRAM bandwidth or panel timing.
 - **`lv_label_set_text()` invalidates unconditionally**, even when the text is
   identical — so setting an unchanged value still forces a repaint. All label
   updates go through `label_set_if_changed()`.
-- **WiFi must be brought up before `display_init()`.** The bounce refill ISR
-  reads PSRAM, which shares the cache with flash; an NVS write while the panel
-  is running faults it with *"Cache disabled but cached memory region
-  accessed"*.
+- **Display bring-up is two-phase, and both orderings are load-bearing.**
+  `display_alloc()` runs *before* WiFi: the bounce buffers need two contiguous
+  25.6KB internal DMA blocks, and WiFi's RX buffer churn fragments the heap
+  within seconds — observed as a boot-loop with 84KB free and no block big
+  enough. `display_start()` runs *after* WiFi: once scan-out begins, the
+  bounce refill ISR reads PSRAM, which shares the cache with flash, and an
+  NVS/PHY write would fault it with *"Cache disabled but cached memory region
+  accessed"*. Allocate early, scan late.
 
 ## Partitions
 
@@ -256,5 +260,9 @@ enabled (the panel cannot stream straight from PSRAM), which is exactly why
 flash writes are dangerous while the panel runs: the refill ISR reads PSRAM,
 which shares the cache with flash on the S3, so an NVS write faults it with
 *"Cache disabled but cached memory region accessed"*. All flash writes happen
-before `display_init()` and `CONFIG_ESP_WIFI_NVS_ENABLED` is off to keep the
-WiFi stack from writing later.
+before `display_start()` and `CONFIG_ESP_WIFI_NVS_ENABLED` is off to keep the
+WiFi stack from writing later. Static buffers beware: `.bss` lives in the
+same internal RAM the bounce buffers come from, with only ~33KB of slack
+after the panel is up — a few KB of new static array is enough to matter
+(the trend ring is deliberately time-bucketed down to ~720 bytes for this
+reason).