* fix(wifi): make Connect work from the setup AP
Joining a network from LEDMatrix-Setup has to take the AP down first, which
drops the phone that sent the request. The connect endpoint answered only
after the attempt finished, so the browser never got a reply and the WiFi
tab's Connect button appeared to do nothing.
- /wifi/connect answers 202 immediately while the AP is active and connects
in a background thread; the result (never the password) is reported via
/wifi/status as last_connect_attempt. A second connect while one is
pending gets 409.
- connect_to_network holds a /tmp flag for the attempt; the monitor daemon
skips AP management while it is fresh. Previously the daemon's
disconnected counter, accumulated over the whole AP session, re-enabled
the AP on its next tick in the middle of the connect.
- The WiFi tab and captive setup page explain the handoff up front, and on
reopening show why the last attempt failed. The wrong-password message
now works: the route sets the error_type the captive page checks.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(wifi): serialize connect attempts on both paths
Addresses CodeRabbit review on #571:
- Check for a pending attempt before branching on AP state. A background
attempt takes the AP down long before it finishes, so a second click
used to bypass the 409 and start a competing synchronous connect.
- Record pending for the synchronous (non-AP) path too, so two requests
can't overlap and have the first clear the daemon's in-progress flag
while the second is still connecting.
- Clear the pending state if the background thread fails to start, rather
than refusing every later request until restart.
- Say the setup network returns "within a few minutes": a stale flag plus
the daemon's grace period can take longer than one.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
