[ClutchplateDude]

Fixes #307

What

WIFI_MODE_ATTEMPT_INFRASTRUCTURE_FAIL_TO_AP had two pre-existing defects, explicitly deferred from #295 (analysis by @rbhbokka in this comment):

1. The mount was unreachable after failover

After infraToAPFailover() switched the radio to the access point, WifiControl::loop() kept hitting the return in the _status != WL_CONNECTED branch on every pass — the soft-AP was up and the port bound, but tcpLoop()/udpLoop() were never reached again, so no client was ever serviced.

One condition was answering two different questions ("should we attempt failover" vs "are the servers up"). This PR splits them:

• the station-monitoring block now stops entirely once _failedOver is set (this also prevents a post-failover status flap from re-running establishServers() and killing the AP client), and infraToAPFailover() remains self-guarding via _infraStart;
• a _tcpServer == nullptr || _udp == nullptr lifecycle guard now controls the early return.

2. getIP() / getStatus() reported the wrong interface after failover

Both keyed off the compile-time WIFI_MODE, so after failover the UDP discovery reply and the :GN# response advertised WiFi.localIP() (0.0.0.0 or the stale station IP) instead of the AP address, plus station status/SSID fields that no longer applied.

This PR adds a _failedOver runtime flag set by infraToAPFailover() and consulted in loop(), getIP(), and getStatus(), keeping WIFI_MODE as the policy input. After failover the mount now reports exactly what a WIFI_MODE_AP_ONLY mount would ("Access Point," mode label, AP-shaped fields, softAPIP).

Behavior notes

• WIFI_MODE_INFRASTRUCTURE: unchanged while connected; while disconnected the server loops now no-op on the dead interface instead of early-returning (they re-arm automatically on reconnect, which was already handled by the status-change block).
• WIFI_MODE_AP_ONLY: no behavioral change.
• If softAP() itself fails to start, the mount ends in the same dead state as before this PR (servers never established); no regression.

Testing

Compiled all three WIFI_MODEs locally with pio run -e esp32 (each is a distinct compile-time path) — all pass. Runtime testing still needs real hardware: an ESP32 in failover mode plus an infrastructure network that refuses the credentials.

⚠️ Note: CI does not compile this file at all — matrix_build.py never sets WIFI_ENABLED. A follow-up to add a WIFI-enabled matrix variant would give this code path CI coverage (happy to do that separately).

🤖 Generated with Claude Code