Add SIM868 cellular fallback for tracking uploads (untested, no SIM card)

modules/app_cellular.py: uses the SIM868's built-in AT-command HTTP(S)
client (AT+HTTPINIT/HTTPPARA/HTTPACTION/HTTPREAD) instead of a real
ppp0 interface, since the module's GNSS (polled continuously by
app_gps.py) and its GSM/GPRS radio share the same physical UART
(/dev/serial0) - a pppd/chat dial-up would take over that port
entirely and starve GNSS polling. Staying in AT-command mode lets
cellular HTTP calls interleave safely through the same serial lock.

Only carries small JSON tracking batches, never dashcam video -
cellular is far too slow/limited for that, and the modem's HTTP AT
interface has too small an internal buffer anyway. Dashcam uploads
remain WiFi/Ethernet-only, unchanged.

modules/app_upload.py: tracking-batch upload always tries WiFi/
Ethernet first; only on a connection-level failure (not an HTTP error
status, which means the server was reached) does it retry over
cellular. Exposes last_network_path/cellular_fallback_configured in
/api/upload/status; UI shows which path the last batch used.

Feature-flagged off by default via new YARIS_CELLULAR_ENABLED/
YARIS_CELLULAR_APN/_APN_USER/_APN_PASS keys in db/upload_creds.env
(all blank by default) - has zero effect on the existing WiFi upload
path unless explicitly configured. Regression-tested against the real
deployed server that normal WiFi uploads are unaffected while
cellular stays unconfigured.

*** UNTESTED against real cellular hardware - no SIM card was
*** available. See docstrings in app_cellular.py and PLAN.md for
*** exactly what needs validation once a SIM card is available.

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

PLAN.md

@@ -353,10 +353,37 @@ dedupe + path-traversal rejection, bad-API-key rejection, toggle-off correctly p
 dashcam uploads) and on the real Pi (its actual ~1800-row pre-feature backlog drained and
 confirmed matching row counts on the server via direct psql query, live upload status visible on
 `/dash`). Committed+pushed (`4ff99f0`, `c4db1ab`, `8dc304e`), deployed on both unraid and the Pi.
+Exposed externally at `https://yaris.ceaf.dev` via the user's Cloudflare Tunnel (public hostname
+added in the Cloudflare dashboard, pointing at `192.168.10.10:8098`).
 
-Not attempted (future, no action needed unless requested): SIM868 GSM/GPRS cellular fallback
-uplink for uploads when no network path to the server is available at all (today uploads need
-the Pi to reach `yaris.ceaf.dev`, e.g. via home WiFi) — remains a possible future enhancement.
+### SIM868 cellular fallback for tracking uploads — built, UNTESTED (no SIM card available)
+`modules/app_cellular.py` gives the tracking-upload path a fallback over the SIM868's cellular
+data connection when WiFi/Ethernet is unreachable. Design notes:
+- Uses the SIM868's built-in AT-command HTTP(S) client (`AT+HTTPINIT`/`HTTPPARA`/`HTTPACTION`/
+  `HTTPREAD`) rather than a real `ppp0` network interface. Reason: the SIM868's GNSS (polled
+  continuously by `modules/app_gps.py`) and its GSM/GPRS radio share the *same* physical UART
+  (`/dev/serial0`) — a classic `pppd`/`chat` dial-up would put that port into raw PPP framing for
+  as long as the link is up, starving the GNSS polling thread. Staying in AT-command mode lets
+  cellular HTTP calls interleave safely through the same serial lock
+  (`modules.app_gps._serial_lock`) — each exchange just briefly delays the next GPS poll.
+- Only carries small JSON tracking batches, **never** dashcam video — cellular data is far too
+  slow/limited for multi-MB video files, and the modem's HTTP AT interface has a small internal
+  buffer unsuited to them anyway. Dashcam uploads remain WiFi/Ethernet-only, unchanged.
+- `modules/app_upload.py`'s tracking-batch upload always tries WiFi/Ethernet (`requests`) first;
+  only on a connection-level failure (no route/DNS/timeout — as opposed to an HTTP error status,
+  which means the server WAS reached) does it retry the same batch over cellular.
+- Feature-flagged off by default: `YARIS_CELLULAR_ENABLED`/`YARIS_CELLULAR_APN`/
+  `YARIS_CELLULAR_APN_USER`/`YARIS_CELLULAR_APN_PASS` added to `db/upload_creds.env`, all blank
+  by default so this has zero effect on the already-verified WiFi upload path until the user
+  fills in an APN once they get a SIM card. Regression-tested (against the real server) that
+  normal WiFi uploads are completely unaffected while cellular is unconfigured.
+- `/dash` upload-status card now shows which path (`wifi`/`cellular`) the last successful batch
+  used, and whether cellular fallback is configured.
+- **Needs validation once a SIM card is available** — exact AT command dialect/timing (SIMCOM
+  firmware revisions vary slightly), and whether `AT+HTTPSSL` works for the HTTPS
+  `yaris.ceaf.dev` endpoint on this specific module's firmware (if not, a documented fallback is
+  a plain-HTTP router port-forward path, avoiding the need for the modem's TLS stack to validate
+  a cert chain).
 
 ## Working Notes / Environment Gotchas