bug: Connecting to a visible Wi-Fi SSID can time out with HTTP 500

### Bug description

`POST /wifi-manager/v1.0/connect` can return **HTTP 500** with `Could not stablish a wifi connection in time` even when the SSID is visible in scan results and the credentials are correct.

**Affects `1.4-dev`.** Reproduced live during RF QA (visible-SSID connect). Hidden-SSID connect on the same vehicle later succeeded and got a DHCP lease.

`WifiManager.connect_to_network` (`core/services/wifi/wifi_handlers/wpa_supplicant/WifiManager.py`) selects the network, then polls `wpa_state == COMPLETED` for **20 seconds**. If association is not complete by then it raises `RuntimeError("Could not stablish a wifi connection in time.")`, which surfaces as 500. There is no retry, no distinct “still associating” status, and a typo in the error string (`stablish`).

Operators see a failed connect in the UI even though the AP is visible. A later hidden-SSID connect on the same radio can work, so this is not a hard “wifi is down” failure.

### Steps to reproduce

1. On BlueOS `1.4-dev`, with a reachable 2.4 GHz AP whose SSID appears in `GET /wifi-manager/v1.0/network`.
2. Connect to that **visible** SSID (UI or API), for example:

```bash
curl -sS -D - -X POST \
"http:///wifi-manager/v1.0/connect" \
-H 'Content-Type: application/json' \
-d '{"ssid":"","password":""}'
```

3. Observe: `HTTP/1.1 500` and body containing `Could not stablish a wifi connection in time`.
4. (Contrast) Connecting via hidden-SSID on the same DUT can still complete and obtain an IPv4 lease.

### Primary pain point(s)

Joining a scanned network can fail spuriously. The UI reports a hard error after 20s with no way to tell “wrong password” from “association too slow”.

### Additional context

- Suggested direction: distinguish association timeout from auth failure; consider a longer timeout or continuing to report connecting instead of 500; fix the `stablish` typo.
- Live pin: `bluerobotics/blueos-core:1.4-dev`. First failure was not retried (RF first-fail policy). Other DUTs on the same suite passed visible-SSID connect.

### Prerequisites

- [x] I have checked to make sure that a similar request has not already been filed or fixed.

Read core/services/wifi/wifi_handlers/wpa_supplicant/WifiManager.py, focusing on WifiManager.connect_to_network and the POST /wifi-manager/v1.0/connect path. Reproduce the visible-SSID case with the curl request and inspect how wpa_state polling handles association and authentication failures. Done means the endpoint no longer reports a transient association timeout as an indistinguishable HTTP 500, and the reported error text is corrected.

Written by the indexing model from the issue text.