Document real-hardware phone-relay test results in PLAN.md

Deployed and tested the phone-relay feature end-to-end for real:
found and fixed a deploy gap (CORS fix wasn't rebuilt into the actual
remote server's Docker image, only pulled on the Pi - surfaced as a
generic "TypeError: Failed to fetch" in the browser). After fixing,
measured real throughput from server-side chunk timestamps: ~1.11MB/s
via phone relay (home WiFi) vs ~9-10Mbit/s for the Pi's own direct
upload - statistically the same. Confirms the relay provides no speed
benefit when the phone is on the same home WiFi as the Pi, since the
download-to-phone leg pays the same congested-radio cost either way.
Documented this finding plus a follow-up idea (per-clip browse/select
upload from the phone, not yet designed).

PLAN.md

@@ -525,10 +525,39 @@ each chunk to the mock-backed server -> verify the reassembled file matches the
 byte-for-byte via SHA256 -> mark uploaded on the Pi -> confirm it drops out of the pending list.
 Also verified: path-traversal attempts on `/api/dash/file/` correctly 404, the relay
 heartbeat/stop lease correctly pauses/resumes `_upload_dashcam_files()`, and the sha256 cache
-table is populated and reused across repeated `/api/dash/pending` calls. **Not yet tested on a
+table is populated and reused across repeated `/api/dash/pending` calls.
-real phone against the real deployed server** — the wire protocol and every server-visible
+
-behavior is verified, but real mobile-browser quirks (background-tab throttling, flaky cellular
+**Deploy gotcha found**: the CORS fix in `server/app.py` was initially deployed to the Pi but not
-mid-transfer) haven't been exercised against live hardware yet.
+rebuilt on the actual remote server (the server's Docker image bakes `app.py`/`modules/` in at
+build time via `COPY`, so a plain `git pull` + container restart isn't enough — needs
+`docker compose build api && docker compose up -d api`). Without it, the phone's cross-origin
+`fetch()` calls to `yaris.ceaf.dev` were silently blocked by the browser's CORS policy, which
+surfaces in JS as a generic, unhelpful `TypeError: Failed to fetch` — worth remembering as the
+first thing to check if this error reappears after a future server-side change.
+
+**Tested for real against a real phone and the real deployed server** (first end-to-end proof
+beyond the local simulation above): the initial `/api/dash/pending` call took ~25 minutes for a
+one-time full-backlog SHA256 hash of all 87 files (~28GB, no cache existed yet) — after that,
+repeat calls returned in ~0.13s. The user then successfully relayed a real file from their phone
+(home WiFi) partway through (10/~12 chunks) before stopping to check something important: **is
+the relay actually faster, given the phone downloads from the Pi over the same congested radio
+diagnosed as the bottleneck?** Measured directly from chunk-arrival timestamps on the server:
+**~1.11MB/s (~8.9Mbit/s) for the phone-relay path — statistically the same as the ~9-10Mbit/s
+measured for the Pi's own direct Cloudflare upload** earlier this session. **Conclusion: when the
+phone is on the same home WiFi as the Pi, the relay provides no speed benefit** — the
+download-to-phone leg pays the exact same slow-radio cost as a direct Pi upload would, and the
+phone's reupload leg then goes out through the same home internet connection anyway, adding an
+extra hop for no gain. The relay only has genuine value when the phone's *second* leg differs
+meaningfully from the Pi's own path — e.g. cellular data with better upload than the home ISP, or
+uploading after physically leaving home with files already grabbed locally. Stopped the test relay
+(`POST /api/dash/relay/stop`) and confirmed the Pi's own background uploader resumed the same
+file's chunked upload exactly where the phone left off (shared `/status`/`.upload_tmp` state on
+the server made this seamless, no wasted re-transfer).
+
+**Next idea (not yet built)**: the user wants a way to browse/preview individual dashcam clips on
+the phone and select specific ones to view or upload (as opposed to bulk-relaying the entire
+backlog) — useful for "just grab this one important clip" rather than a wholesale speed
+optimization. Not scoped/designed yet.
 
 ## Working Notes / Environment Gotchas