tfaour
878909b302
Two bugs found testing against a real (partially-configured) server: - The reachability check hit HEAD / with -- our server only registers GET on that route, so it always got a 405. Harmless for the check itself (any completed HTTP response counts as "reachable"), but noisy and semantically wrong. Points at GET /health instead, which exists for exactly this. - fetch_and_display() failing before any pixel data was sent (e.g. a 400/404 on /frame/image) was treated the same as a mid-stream failure, which skips drawing a status screen to avoid compounding flashing on top of an already-refreshed panel. But a pre-stream failure never touches the panel at all, so skipping the status screen there just left the old provisioning QR code on screen with no indication anything had gone wrong. fetch_and_display() now reports whether streaming ever started so the caller can tell the two cases apart. - The status screen now always shows on the very first successful connection after (re)provisioning, regardless of outcome, via a new "connected_once" NVS flag that frame_config_save() resets on every fresh provisioning event. Later wakes skip it on success (straight to the photo) but still show it on any failure, matching the intent from the original status-screen feature.