fix: schema migration forces clean repaint on first err-border-aware boot

Without this, devices upgrading from the old buggy fill-on-error firmware
get stuck on yellow forever: the new code reads NVS_KEY_ERR_BORDER == 0
(default — the old firmware never wrote that key), so the next 304 sees
no err flag and skips the redraw. NVS img_id matches what the server is
serving, so server says "you're current" indefinitely.

Add NVS_KEY_SCHEMA_V. On boot, if stored version is below
NVS_SCHEMA_VERSION (currently 1), treat errBorder as set for this cycle
and bump schema_v. The next 304 then redraws from LittleFS (the cached
.bin survives flashing) and clears the flag.

Tests: FW-06f locks in the upgrade path (schema_v missing → redraw on
304). FW-06g asserts the migration is one-shot (post-bump → no redraw
on steady-state 304). FW-06d updated to set schema_v explicitly so it
represents the post-migration steady state.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

src/config.h

@@ -31,6 +31,11 @@
 #define NVS_KEY_IMG_ID      "img_id"
 #define NVS_KEY_DRAW_NEEDED "draw"
 #define NVS_KEY_ERR_BORDER  "err"     // set when display is showing a sync-fail border; force a clean redraw on next 200/304
+#define NVS_KEY_SCHEMA_V    "schema_v"
+
+// Bump when introducing a schema migration. Each new value can force a one-shot
+// recovery action on first boot of the new firmware.
+#define NVS_SCHEMA_VERSION  1
 
 // Width of the sync-fail / no-WiFi border, in pixels.
 #define BORDER_THICKNESS_PX 16