bug: Hotspot on 5 GHz cannot be joined (it copies the last WiFi channel)

## Pain

The BlueOS hotspot shows up in the WiFi list, but **phones and laptops cannot join it**.

The password is the default (`blueosap`). This is not a wrong-password problem. The join fails earlier, during association. The phone just says "connection failed". A laptop says the network disappeared / association timed out.

If ethernet is also down, you have **no way in**. The hotspot looks like a recovery path, but it does not work.

## Why it is 5 GHz

On Raspberry Pi OS Bullseye, the hotspot uses **the same channel as `wlan0`** (the last / current WiFi channel).

If `wlan0` was last on 5 GHz (even if it is not connected now), hostapd starts in 5 GHz (`hw_mode=a`). There is no "always use 2.4 GHz" fallback.

Related wish (band picker): https://github.com/bluerobotics/BlueOS/issues/1735
This issue is different: the hotspot **does start** on 5 GHz, but **clients cannot join**.

## Seen on

| | |
|---|---|
| Board | Raspberry Pi 4 Model B Rev 1.2 |
| WiFi chip | BCM43455 (`brcmfmac`) |
| OS | Raspberry Pi OS **Bullseye** (32-bit) |
| BlueOS | `1.4-dev` |
| WiFi stack | `wpa_supplicant` + `hostapd` on virtual `uap0` (not NetworkManager / `create_ap`) |

SSID: `BlueOS (25cfe9)`
hostapd was: **channel 36**, **5180 MHz**, `hw_mode=a`, `wpa_pairwise=TKIP`, `rsn_pairwise=CCMP`.

Same default password **did** work on a Pi 5 Bookworm hotspot that was on **2.4 GHz** (channel 9).

## How to reproduce

1. Use a Pi 4 on Bullseye, BlueOS hotspot enabled (default password).
2. Let `wlan0` sit on a 5 GHz channel (scan, or a previous 5 GHz client connection). You do not need to stay connected.
3. Start / restart the hotspot.
4. On a phone or laptop, look for `BlueOS (xxxxxx)` — it should show as 5 GHz.
5. Try to join with `blueosap`.

**Expected:** you join, get `192.168.42.x`, open `http://192.168.42.1`.

**Actual:** SSID is visible. Join fails on phone and laptop. Ethernet (if it is also broken) cannot save you.

## Notes

- `wlan0` can be disconnected (`NO-CARRIER`) and still report channel 36. The hotspot still copies that channel.
- 5 GHz AP on this Pi 4 chip + `uap0`, together with TKIP in the WPA2 config, is a bad mix for modern phones.
- Please keep the hotspot on **2.4 GHz** unless the user picks 5 GHz and we know clients can join.

Start by tracing the hotspot startup and channel-selection entry points for wpa_supplicant, hostapd, and virtual uap0 on Raspberry Pi OS Bullseye. Reproduce with a Pi 4 whose wlan0 reports a 5 GHz channel, then verify that the default hotspot stays on 2.4 GHz and clients can associate, obtain a 192.168.42.x address, and open 192.168.42.1.

Written by the indexing model from the issue text.