Document phone-relay hotspot+cellular test findings in PLAN.md

Live-tested the away-from-home hotspot+cellular relay scenario. Found the
netwatch reconnect bug (documented in Phase 6 update) during this test.
Confirmed the relay architecture itself needs no code changes - the
TypeError: Failed to fetch was a phone-OS network-switching behavior
(won't route internet traffic over cellular while connected to a
no-internet WiFi), not a CORS/code issue - ruled out via a plain page
navigation test. Testing this fully requires being genuinely away from
home or manually forcing cellular use on the phone.

Co-authored-by: Copilot <[email protected]>

PLAN.md

@@ -236,6 +236,20 @@ is a no-op when already on home WiFi); `http://yaris.local/` and `http://<pi-lan
 HTTP 200 with no port number from another machine on the network. (Real hotspot SSID/password and
 the Pi's LAN IP are intentionally not recorded in this file — see local, non-committed notes.)
 
+**Update — real-hardware bug found + fixed (hotspot->home reconnect was flaky)**: while testing
+the phone-relay feature live (see Phase 9 update below), `yaris-netwatch` repeatedly logged "home
+WiFi not found" 4 times in a row over ~13 minutes while sitting right next to the router — a real
+regression from the original design, not a one-off fluke. Root cause: a plain `nmcli con up
+home-wifi` straight out of AP mode relies on NM's scan cache for `wlan0`, which is stale/empty
+coming out of AP mode (the radio can't scan while acting as an AP - see above). A single
+`--wait 20` connect attempt gave up before a fresh scan could land. Fixed `yaris-netwatch.sh` to
+explicitly drop the AP connection first (releases the radio), force `nmcli device wifi rescan`,
+wait for it to settle, then retry the connect (longer 30s wait) up to 2 times before conceding and
+restoring the hotspot. Bumped `yaris-netwatch.service`'s `TimeoutStartSec` to 180s (retry loop can
+take up to ~80s, default systemd 90s start timeout was too tight). Verified fixed on real hardware:
+both hotspot->home transitions after the fix recovered in ~7 seconds (previously failing outright).
+Deployed: `sudo cp deploy/yaris-netwatch.sh /usr/local/bin/... && cp .service ... && daemon-reload`.
+
 ### Phase 7: app_db.py / app_sql.py fixes — DONE
 Neither file was called from `app.py` or anywhere else - orphaned from a prior iteration. Fixed:
 - `app_db.py`: applied a prior-session stash fix - resolves `.env` path via `__file__` (was
@@ -565,6 +579,36 @@ the phone and select specific ones to view or upload (as opposed to bulk-relayin
 backlog) — useful for "just grab this one important clip" rather than a wholesale speed
 optimization. Not scoped/designed yet.
 
+**Update — tested the "away from home" hotspot+cellular scenario for real, found a real phone-OS
+limitation (not a code bug)**: the user asked to test the specific scenario the relay feature was
+actually designed for — phone connects to the **Pi's own hotspot** (not home WiFi) to download
+pending files, then re-uploads using the phone's **cellular data**, bypassing the Pi's own (in
+hotspot mode, nonexistent) internet connection entirely. Confirmed via code review this needs zero
+changes: `/api/dash/relay/config` already hands the phone the public `https://yaris.ceaf.dev`
+`SERVER_URL` (not a LAN-only address), so the re-upload leg was always going to be internet-bound
+regardless of which physical network carries it.
+
+Live-tested with a real dummy file (dashcam upload toggle paused first so the Pi's own uploader
+couldn't grab it before the phone did): got `TypeError: Failed to fetch` trying to relay. Confirmed
+via a direct test (loading `https://yaris.ceaf.dev/health` as a plain page navigation, not a
+`fetch()`, ruling out CORS) that **the phone's own OS was declining to route internet-bound traffic
+over cellular while still associated with the Pi's no-internet-gateway hotspot WiFi** — it only
+succeeded once the phone auto-fell-back to the home WiFi network (which does have internet)
+instead. This is a phone/OS-level "smart network switching" behavior (common on both iOS and
+Android to avoid using a WiFi network with no internet gateway) that cannot be fixed in this
+project's code — the architecture is sound and was already proven correct in the local end-to-end
+simulation and the byte-for-byte reassembly tests earlier in this phase.
+
+**Practical implication**: testing this exact scenario **at home is inherently confounded** — the
+phone always has a known-good home WiFi it can silently fall back to, defeating the test. A true
+validation needs either (a) actually being away from home with no known WiFi in range, forcing the
+phone to use cellular for internet traffic, or (b) manually disabling the phone's WiFi (or its
+"switch to mobile data automatically" setting) while connected to the Pi's hotspot, to force
+cellular use for this one operation. Not yet re-tested under either condition.
+
+**Side-fix from this test session**: found and fixed a real, unrelated bug in `yaris-netwatch.sh`
+during this same test — see the Phase 6 update above.
+
 ## Working Notes / Environment Gotchas
 
 - **Pi credentials/SSH**: `ssh yaris@<pi-ip>`. Confirm current IP before connecting (varies by