bug: Concurrent Wi-Fi scans never return HTTP 425 (scan_busy is not enforced)

### Bug description

The Wi-Fi scan route is supposed to return **HTTP 425 Too Early** when a scan is already in progress (`BusyError` → `StackedHTTPException` in `core/services/wifi/main.py`). Live concurrent `GET /wifi-manager/v1.0/scan` calls both return **200**.

**Affects `1.4-dev` (Bookworm / NetworkManager path).** Reproduced on a Pi 5 Navigator DUT: two overlapping scans returned `[200, 200]`.

`BusyError` is only raised by the **wpa_supplicant** socket timeout (`wifi_handlers/wpa_supplicant/wpa_supplicant.py`). The NetworkManager backend (`wifi_handlers/networkmanager/networkmanager.py`) has a background `_autoscan` and `request_scan`, but **never raises `BusyError`**. `GET /scan` therefore always succeeds with the current list.

Clients that treat 425 as “retry later” never see it on current images. Two scans can hit NetworkManager at once with no busy signal.

### Steps to reproduce

1. On BlueOS `1.4-dev` (NetworkManager wifi stack):

```bash
curl -sS -o /dev/null -w '%{http_code}\n' "http:///wifi-manager/v1.0/scan" &
curl -sS -o /dev/null -w '%{http_code}\n' "http:///wifi-manager/v1.0/scan" &
wait
```

2. Observe: both lines are `200`.
3. Expected (per the route handler and failure-mode card): one request 425 while a scan is busy.

### Primary pain point(s)

There is no way for a client to back off when the radio is already scanning. Overlapping scans are silent no-ops or races instead of a typed busy.

### Additional context

- Suggested fix: either raise 425 from the NetworkManager path when a scan is already in flight, or document that 425 is wpa_supplicant-only and stop advertising `scan_busy` as a general contract.
- Adjacent: https://github.com/bluerobotics/BlueOS/issues/4159 (remove unknown SSID → 200).

### Prerequisites

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

Start with core/services/wifi/main.py and compare the BusyError handling in wifi_handlers/wpa_supplicant/wpa_supplicant.py with the NetworkManager implementation in wifi_handlers/networkmanager/networkmanager.py. Reproduce the issue with the two concurrent curl requests against /wifi-manager/v1.0/scan. Done means the documented scan_busy contract is consistently enforced for the NetworkManager path, or its scope is explicitly changed and documented.

Written by the indexing model from the issue text.