docs: correct the false Wi-Fi premise; add UI and live-tracking phases

The plan's headline section claimed the Rider 650 has on-device Wi-Fi and a
Data Sync menu that uploads to Bryton's cloud with no phone involved. It
does not. The unit has ANT+ and Bluetooth only; its sole sync route is BLE
to the Bryton Active app. Confirmed on the physical device, corroborated by
BikeRadar's hands-on. Likely origin: conflation with the Rider 750 / S800,
which do have Wi-Fi.

Impact is narrower than it first appears and no built code is invalidated:
everything downstream of Bryton's cloud never depended on how a ride got
into that cloud, so the poller, ingestion, schema, wear engine and all of
Phase 0 stand. What was invalidated is the product promise — Phase 1 was
called "Zero-touch ride history" and claimed to fix the original complaint
(having to remember to open the Active app). It does not; it is one-tap.
Renamed accordingly rather than leaving the doc overclaiming.

Corrections propagated everywhere the premise had spread: PLAN.md's opening
sections, Phase 1, top risks (the chain is now longer and has a human link
that fails silently — earns a "nothing ingested in N days" nudge), and the
verification checklist; DECISIONS.md D3's justification; README.md, which
was additionally stale on nearly every other point (claimed no code written,
Postgres, compose, four containers); and RESEARCH.md, where the claim
originated under a "verified" header it had not earned. RESEARCH.md is
annotated rather than rewritten — it is a record of what was found, and the
correction is part of that record. USB path facts are marked unverified too,
since they came from the same unverified batch.

D20 records the process lesson: the plan contained the right check ("first
action before writing any code"), it was never run, and nothing downstream
required it to have been. Device capabilities get confirmed on the device
before being written as fact.

Also adds the two phases requested before this came up, both grounded in
feasibility research rather than assumption:
- Phase 1A, an open-ended UI pass done together, including the verbose field
  surface driven off activity_field_inventory.
- Phase 1B, live tracking. Constrained hard by reality: iOS suspends
  backgrounded PWAs and implements no Web Bluetooth, and Bryton's own Live
  Track needs the phone relaying over BLE, so the tracking client cannot be
  our PWA. Shape that works is OwnTracks POSTing to our API for position,
  with the server deriving distance/pace/elevation; HR and power need BLE and
  are explicitly a second-class opt-in, not a blocker. Two rules written in:
  live positions must never become activities (invariant #6), and "no privacy
  zones, ever" does not extend to a public live link.

Inserted as 1A/1B rather than renumbering Phases 2-5, whose numbers are
referenced from DECISIONS.md, deploy/README.md and code comments.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01R2ZKeWkZV7ehf7fivrAkkG

docs/RESEARCH.md

@@ -8,20 +8,31 @@ architecture design; Sonnet for the two breadth surveys). Confidence is flagged
 
 ## 1. Getting data off the Bryton Rider 650
 
-### Device facts (verified 2026-09-20)
+### Device facts (dated 2026-09-20 — item 2 was WRONG, see correction)
 
-The Rider 650 is **modern generation**. Two independent extraction paths, both good:
+> ⚠️ **Correction, 2026-09-22.** Item 2 below is false and was never verified on the device. The
+> Rider 650 has **no Wi-Fi** — ANT+ and Bluetooth only — and no `Data Sync` menu entry. Its only
+> sync route is BLE to the Bryton Active app. Confirmed on the physical unit, corroborated by
+> BikeRadar's hands-on ("ANT+ and Bluetooth connectivity", syncing via "Bryton's Active App"). The
+> likely origin is conflation with the Rider 750 / S800, which do have Wi-Fi. The header on this
+> section originally read "verified 2026-09-20" — it was not verified; that word is the reason the
+> claim propagated into `docs/PLAN.md` as a premise and survived an entire phase of work. See
+> `docs/DECISIONS.md` D20. **Item 1 (USB) is still believed correct but is also unverified against
+> the device — treat it as an open question, not a finding, until someone plugs the unit in.**
+
+The Rider 650 is **modern generation**. Extraction paths:
 
 1. **USB mass storage.** Mounts as a plain FAT volume labelled `Bryton`; activities are native
    Garmin-format `.fit` files in `Bryton/Activities/`. No driver, no udev rule needed beyond
    convenience — it is plain `usb-storage`. Filter on `ID_FS_LABEL=Bryton`.
    *Caveat:* sources disagree across models about whether the folder is `Activities/`, `Actives/`,
    or the volume root. Discover it at runtime with a recursive glob; don't hardcode.
-2. **On-device Wi-Fi.** `Main Menu -> Data Sync` lets the head unit join a Wi-Fi hotspot directly
-   and upload tracks to Bryton's cloud **with no phone and no Bryton Active app**. This is the
-   key finding — it removes the phone from the pipeline entirely.
-   *Still to verify:* whether it uploads automatically on joining Wi-Fi, or only when you
-   manually trigger Data Sync from the menu. Two-minute test; do it first.
+   *Status:* **unverified on the device.**
+2. ~~**On-device Wi-Fi.** `Main Menu -> Data Sync` lets the head unit join a Wi-Fi hotspot directly
+   and upload tracks to Bryton's cloud **with no phone and no Bryton Active app**.~~
+   **FALSE — the device has no Wi-Fi and no such menu.** See the correction above. The real path is
+   `head unit -> BLE -> Bryton Active app -> Bryton cloud`, so the phone cannot be removed from the
+   pipeline by any means available to this project.
 
 ### Bryton Active cloud API (reverse-engineered, working)
 
@@ -330,8 +341,12 @@ can't delete history. 3-2-1. **Test restores** — an untested backup is a hypot
 
 ## 5. Open questions to resolve before/while building
 
-1. **Does Rider 650 Data Sync upload automatically on joining Wi-Fi, or only on manual trigger?**
-   Determines how completely the phone is removed from the loop. Two-minute test.
+1. ~~**Does Rider 650 Data Sync upload automatically on joining Wi-Fi, or only on manual trigger?**~~
+   **RESOLVED 2026-09-22 — the question was malformed.** There is no Wi-Fi and no Data Sync on this
+   device; the phone cannot be removed from the loop at all. See the correction at the top of this
+   file and `docs/DECISIONS.md` D20. *This was the single most consequential open question in this
+   list, it was marked "two-minute test," and it went unanswered while an entire phase was planned
+   and built on the assumed answer.*
 2. **Exact on-device `.fit` path** — documented as `Bryton/Activities/` for the 650, but sources
    disagree across models. One `ls -R` settles it.
 3. **Bryton's FIT encoder quirks** — untested against `fitdecode`. Get one real 650 file and run it