display: tear-free frame path via triple buffering + scan tracking

draw_bitmap on a direct fb pointer only updates the driver's
cur_fb_index; the DPI DMA reloads that index at the END of the
in-progress frame scan (~21ms period at ~47Hz). Under double
buffering, flipping and immediately decoding the next frame into
the other fb writes a buffer the DMA may still be scanning out —
a torn frame. This regime is common now that the TCP window fix
delivers frames back-to-back (decode starts ~6ms after flip).

Fix with zero added latency: num_fbs 2 -> 3 (+1.15MB PSRAM of 25MB
free), track the actually-scanning fb via on_refresh_done (fires in
the DMA-done ISR exactly when the DMA reloads cur_fb_index), and
pick the decode target as the fb that is neither pending display
nor scanning. Three buffers minus at most two excluded roles =
always a free one; no waiting on vsync anywhere.

Instrumented: /state tear_guard_engaged counts back-buffer picks
made while the previous fb was still mid-scan — each one is a
frame that would have torn under double buffering.

1 files changed, 5 insertions, 0 deletions

diff --git a/main/http_api.c b/main/http_api.c
index e64ebc9..b9eade0 100644
--- a/main/http_api.c
+++ b/main/http_api.c
@@ -73,6 +73,11 @@ static esp_err_t state_get_handler(httpd_req_t *req)
         (double)heap_caps_get_free_size(MALLOC_CAP_INTERNAL));
     cJSON_AddNumberToObject(root, "free_psram",
         (double)heap_caps_get_free_size(MALLOC_CAP_SPIRAM));
+    // Frames whose decode target was picked while the previous fb was
+    // still mid-scan — each one is a tear the triple-buffer guard
+    // prevented (would-have-torn count under double buffering).
+    cJSON_AddNumberToObject(root, "tear_guard_engaged",
+        (double)display_tear_guard_engaged());
 
     viewport_state_unlock();