Optimize backlog upload speed for tracking rows

The upload loop previously always slept the full 30s UPLOAD_INTERVAL
between batches, even when a full batch was just sent (meaning more
rows were likely still queued). With GPS/OBD rows logged every 5s
locally, an offline/stale device could build up a large backlog that
took a very long time to drain at 100 rows/30s.

- Bump TRACKING_BATCH_SIZE 100 -> 500 (cuts round-trips per backlog).
- Only sleep the full UPLOAD_INTERVAL once actually caught up (a
  short batch came back); while a full batch keeps coming back, drain
  back-to-back with a short CATCHUP_INTERVAL (1s) instead.
- server/app.py: add a sane MAX_TRACKING_BATCH_POINTS (5000) cap on
  the tracking/batch endpoint as a defensive guard against a runaway
  client, independent of the Pi's own batch size.

Verified against the real deployed server: a simulated 1250-row
backlog now drains in 3 batches (~0.35s server round-trip time) instead
of 13 batches spread across ~6.5 minutes of idle sleeping.

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

server/app.py

@@ -17,6 +17,10 @@ STORAGE_DIR = os.environ.get("DASHCAM_STORAGE_DIR", "/data/dashcam")
 MAX_DASHCAM_UPLOAD_MB = int(os.environ.get("MAX_DASHCAM_UPLOAD_MB", "2048"))
 app.config["MAX_CONTENT_LENGTH"] = MAX_DASHCAM_UPLOAD_MB * 1024 * 1024
 
+# Sanity cap on tracking points per request - the Pi client batches in
+# groups of 500, this just guards against a runaway/misbehaving client.
+MAX_TRACKING_BATCH_POINTS = 5000
+
 
 @app.get("/health")
 def health():
@@ -39,6 +43,10 @@ def upload_tracking_batch():
     points = body.get("points")
     if not isinstance(points, list) or not points:
         return jsonify(error="expected a non-empty 'points' list"), 400
+    if len(points) > MAX_TRACKING_BATCH_POINTS:
+        return jsonify(
+            error=f"batch too large - max {MAX_TRACKING_BATCH_POINTS} points per request"
+        ), 400
 
     for p in points:
         if "recorded_at" not in p: