docs: close BUG-21 (GPS-speed fallback verified)

BUGS.md

@@ -24,29 +24,24 @@ When CLOSED, move the entire entry to Resolved — don't duplicate.
   fills the cards immediately on load (and every 15 s) via REST. Needs in-car
   verification.
 
-### BUG-21 — OBD speed drops out mid-drive, replay shows 0 km/h (GPS-only)
-- **Status**: `OPEN` 2026-08-14
-- **Phase**: 29
-- **Symptom**: in the portal trip replay, a ~20-minute stretch of the 2026-08-13 evening
-  drive shows "GPS: 0.0 km/h" even though the car was moving (GPS positions advance).
-- **Cause**: the Pi's OBD adapter (ELM327) stopped returning speed mid-drive — the last OBD
-  speed reading in trip #9 was 22:23:50 UTC and it didn't return until 22:43:41 UTC (trip #10),
-  a ~20-minute gap. During that gap `_log_loop()` logged rows with GPS coords but NULL speed
-  (`insert_tracking(gps_x, gps_y, speed=None, …)`) — there is no GPS-derived speed fallback, so
-  the SPEED column stays NULL and the replay shows 0.0 km/h (`speed_source="gps"`).
-- **Data**: trip #9 has 723 points — 570 with OBD speed, 25 with speed=0, 128 with NULL speed.
-- **Fix**: mirror the Pi's `route_points` GPS-speed fallback in the server's `get_trip_route()`
-  (`server/modules/db.py`) — when OBD speed is missing, derive speed from the previous point's
-  movement (haversine / elapsed time, ≥8 m, ≤220 km/h) so the replay shows the real speed
-  instead of flatlining at 0 km/h. (The Pi's own replay already did this; only the portal was
-  missing it.)
-- **Follow-up**: investigate why the OBD adapter didn't recover for ~20 min (reconnect on
-  stalled reads).
-
 ---
 
 ## Resolved
 
+### BUG-21 — OBD speed drops out mid-drive, replay shows 0 km/h (GPS-only)
+- **Status**: `CLOSED` 2026-08-14
+- **Commit**: `PENDING`
+- **Fix**: the Pi's OBD adapter (ELM327) stopped returning speed for ~20 min on 2026-08-13
+  (last OBD reading 22:23:50 UTC, back at 22:43:41 UTC), so the portal replay flatlined at
+  0 km/h for that stretch. The server's `get_trip_route()` now mirrors the Pi's `route_points`
+  GPS-speed fallback — when OBD speed is missing it derives speed from the previous point's
+  movement (haversine / elapsed time, ≥8 m, ≤220 km/h). The Pi's own replay already did this;
+  only the portal was missing it.
+- **Verification**: trip #9 points at 22:23:55 previously returned speed 0.0 — now return
+  GPS-derived speeds (e.g. 61.9 km/h at 22:23:55, labelled `gps`). API rebuilt + healthy.
+- **Follow-up**: investigate why the OBD adapter dropped for ~20 min (reconnect on stalled
+  reads).
+
 ### BUG-20 — Server trip IDs inflate far beyond the real trip count
 - **Status**: `CLOSED` 2026-08-14
 - **Commit**: `9af71e2`

PLAN.md

@@ -2282,10 +2282,10 @@ logged as `BUG-XX` entries in [BUGS.md](./BUGS.md) (BUG-16 onward) and fixed + v
 - **BUG-20 (server trip IDs inflate) — ✅ FIXED**: `trips.id BIGSERIAL` burned sequence values
   on every upsert (recompute after each upload batch). Fixed: sequence clamped to `MAX(id)`
   after each recompute + one-time renumber migration — trips now 1..10, sequence at 10.
-- **BUG-21 (OBD speed dropout mid-drive) — 🚧 IN PROGRESS**: ELM327 stopped returning speed for
-  ~20 min on 2026-08-13 (22:23:50→22:43:41 UTC). Fix: server `get_trip_route()` now mirrors the
-  Pi's GPS-speed fallback (derive speed from consecutive GPS points when OBD speed is missing),
-  so the portal replay no longer flatlines at 0 km/h. Follow-up: OBD reconnect on stalled reads.
+- **BUG-21 (OBD speed dropout mid-drive) — ✅ FIXED**: ELM327 stopped returning speed for ~20 min
+  on 2026-08-13 (22:23:50→22:43:41 UTC). Fixed: server `get_trip_route()` mirrors the Pi's
+  GPS-speed fallback (derives speed from consecutive GPS points when OBD speed is missing), so
+  the portal replay no longer flatlines at 0 km/h. Follow-up: OBD reconnect on stalled reads.
 
 Open items from the drive — fill in as reported:
 - (none clock-related — BUG-17/BUG-18 closed 2026-08-14).