Distance & calories jump backward when the first GPS fix arrives #11

Problem

Distance and calories jump backward the moment the first GPS fix is accepted. A distance/calorie counter should never decrease during an active session.

Root cause

app.js uses a hybrid distance source that switches to GPS-only as soon as one segment is accepted, discarding all step-estimated distance accumulated before the first fix:

function effectiveDistM() {
  // Hybrid: trust GPS once we have accepted segments, else estimate from steps.
  return state.gpsSegments >= 1 ? state.gpsDistM : stepDistM();
}

state.gpsDistM starts at 0 and only accumulates from the first accepted segment onward (onPos()), so the pre-GPS step distance is dropped.

Repro (via the ?debug window.__sv hooks)

1. Load ?debug, reset counters.
2. __sv.simSteps(1200) → 0.85 km, 53 kcal (step-estimated, stride ~0.706 m).
3. __sv.addGps(0.02) (first accepted 20 m GPS segment) → 0.02 km, 1 kcal.

Distance regresses 0.85 km → 0.02 km (calories 53 → 1) on the GPS handoff. On a real device this happens the moment you step outdoors and get your first fix.

Expected

Distance/calories are monotonic within a session; the GPS handoff must not drop already-counted distance.

Suggested fix

Seed the GPS accumulator with the current step-estimated distance when the first segment is accepted, so GPS continues from the existing baseline rather than from 0. In onPos(), before accepting the first segment:

if (state.gpsSegments === 0) state.gpsDistM = stepDistM();  // carry the pre-GPS baseline

(Alternatively have effectiveDistM() return Math.max(state.gpsDistM, stepDistM()), though seeding once is cleaner and keeps GPS authoritative afterward.)