fix: BUG-20 clamp trips sequence after recompute + renumber migration

BUGS.md

@@ -24,6 +24,20 @@ 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-20 — Server trip IDs inflate far beyond the real trip count
+- **Status**: `OPEN` 2026-08-14
+- **Phase**: 29
+- **Symptom**: the portal shows trip IDs in the tens of thousands (e.g. 25136, 27091) even
+  though there are only ~10 real trips (verified: `COUNT=10`, `MAX(id)=27091`).
+- **Cause**: `trips.id` is `BIGSERIAL`, and `compute_trips_for_device()` upserts every trip on
+  every tracking batch via `INSERT … ON CONFLICT (device_id, start_time) DO UPDATE`. PostgreSQL
+  consumes a sequence value on every INSERT attempt — including the conflict/update path — so
+  the sequence advances by the trip count on every recompute (which runs after every upload
+  batch). Cosmetic only: nothing references `trips.id` as a foreign key (`deleted_trip_markers`
+  keys on `(device_id, start_time)`).
+- **Fix**: clamp the sequence to `MAX(id)` after each recompute in `compute_trips_for_device()`,
+  plus a one-time migration that renumbers existing trips compactly and resets the sequence.
+
 ---
 
 ## Resolved