docs: WiFi role swap + hotspot settings feature (FEAT-11)

- PLAN.md: Hardware section + Architecture #2/#5 updated for wlan1=AP(5GHz), wlan0=uplink
- FEATURES.md: FEAT-11 SHIPPED (hotspot SSID/password UI + 5GHz role swap)
- readme.md: hardware table + hotspot feature line updated
- deploy/readme.md: profile names/bands updated (home-wifi on wlan0, Hotspot-local 5GHz on wlan1)

PLAN.md

@@ -12,9 +12,14 @@ pick up the project without needing prior chat history.
 - **Board**: Raspberry Pi 3 Model B Rev 1.2, 906MB RAM. Confirmed too weak to run an AI coding
   agent — all agent-assisted dev work happens on a separate local machine; the Pi is only used
   for hardware bring-up/testing/deployment via SSH (`yaris@<pi-ip>`).
-- **WiFi**: Dual-radio setup — **TP-Link Archer T3U (RTL8812BU)** USB dongle as `wlan1` for
-  Internet uplink (home WiFi, phone hotspot), onboard BCM43438 as `wlan0` running a permanent
-  AP ("yaris 911" at 10.42.0.1, password "yaris911!"). Both radios active simultaneously.
+- **WiFi**: Dual-radio setup — **TP-Link Archer T3U (RTL8812BU)** USB dongle as `wlan1` and the
+  onboard BCM43438 as `wlan0`. **2026-08-12 role swap**: the fast T3U now hosts the in-car AP
+  ("vroom vroom yaris de course" on 5GHz at 10.42.0.1) for fast phone access (Android dev, video
+  browsing); the weak onboard radio carries the internet uplink (home WiFi "BuzzBis" +
+  phone hotspot, static IP 192.168.50.220, gw 192.168.50.1). Both radios active simultaneously.
+  Tradeoff: away-from-home uploads (dashcam/trip sync) now run over the weak onboard radio — a
+  background task, accepted by owner. A single radio cannot be AP + client at once, so the
+  phone-hotspot uplink cannot also live on wlan1 while it hosts the AP.
 - **GPS/GSM**: Waveshare **SIM868 GSM/GPRS/GNSS/Bluetooth HAT**. GNSS provides live GPS fixes
   (confirmed working, ~7 satellites, ~80s cold-start TTFF). GSM/GPRS cellular is **not in use**
   (no SIM card available); a Huawei **E3372h-153 4G LTE modem** has been purchased as a future
@@ -66,13 +71,16 @@ pick up the project without needing prior chat history.
    OSM tile usage policy. Bounding box is a required CLI arg (the user's own driving area, not
    committed here), zoom 8-15 by default (~14k tiles for a city-plus-suburbs-sized area, well
    under MapTiler's 100k/month free quota).
-2. **WiFi hotspot mode**: **Dual-radio** — the TP-Link Archer T3U (wlan1) handles all internet
-   uplink traffic (home WiFi, phone hotspot), while the onboard WiFi (wlan0) runs a permanent
-   AP ("yaris 911" at 10.42.0.1) that is never taken down by the uplink manager. The hotspot
-   is *only* for local web-UI viewing on a phone/laptop while driving — it is not part of the
-   upload path. Remote-server uploads happen independently via home WiFi (when in range),
-   phone hotspot (Phase 22), or cellular fallback (decision #5). Phone-hotspot auto-connects
-   on wlan1 within ~60s of appearing, falls back to home-wifi when it disappears.
+2. **WiFi hotspot mode**: **Dual-radio** — the fast TP-Link Archer T3U (wlan1) hosts the
+   in-car AP ("vroom vroom yaris de course" on 5GHz at 10.42.0.1), while the onboard BCM43438
+   (wlan0) carries all internet uplink traffic (home WiFi, phone hotspot) and is never taken
+   down by the uplink manager. The hotspot is *only* for local web-UI/Android access while
+   driving — it is not part of the upload path. Remote-server uploads happen independently via
+   home WiFi (when in range), phone hotspot (Phase 22, now on wlan0), or cellular fallback
+   (decision #5). Phone-hotspot auto-connects on wlan0 within ~60s of appearing, falls back to
+   home-wifi when it disappears. **2026-08-12 swap** from the previous arrangement (uplink on
+   wlan1, AP on wlan0) to put the fast radio on the AP for interactive phone work; the weak
+   radio's uplink slowness is accepted because away-from-home upload is a background task.
 3. **Local/remote persistence**: Keep SQLite locally (reliable local write path per trip). The
    original plan paired this with MongoDB Atlas for remote sync (`modules/app_db.py`, fixed in
    Phase 7) — **superseded by decision #4/Phase 9**: the actual remote store is the self-hosted
@@ -81,7 +89,7 @@ pick up the project without needing prior chat history.
 4. **Remote server**: Self-hosted — a custom server/API (e.g. on a home server or VPS) receives
    itinerary and dashcam uploads, rather than 3rd-party managed cloud services.
 5. **Remote upload uplink**: Three paths, tried in order: (1) WiFi/Ethernet via `requests`,
-   (2) phone hotspot via wlan1 when configured and in range (Phase 22), (3) SIM868 GSM/GPRS
+   (2) phone hotspot via wlan0 when configured and in range (Phase 22), (3) SIM868 GSM/GPRS
    cellular fallback (AT-command HTTP client, tracking batches only — no dashcam video).
    Cellular is **untested** (no SIM card). A Huawei E3372h-153 4G LTE modem has been purchased
    to replace the 2G-only SIM868 cellular path once a SIM is available (FEAT-04).