detect_stops: reject progressive movement — a walk is not a stop

[rslayer]

detect_stops: reject progressive movement — a walk is not a stop

Implements the deeper half of "a walk isn't a stop." A stop is one place — points clustered around a common centre. detect_stops only checked spread ≤ radius, so a slow walk/crawl lasting longer than min_stop_minutes was chopped into radius-sized chunks, each reported as a phantom stop (a steady ~190 m walk → 2 "stops"). (Fast movement was already filtered by duration.)

Fix: a cluster is a stop only if it isn't progressively translating — measured by the drift between its first- and second-half centroids. A dwell's halves coincide (random jitter averages out); a walk's drift apart by ~the distance travelled. Reject when drift > 0.5 × stop_radius_m (tunable constant). Clusters < 4 samples are treated as dwells so brief legitimate stops are never dropped. ADR 0014.

Verified (local A/B)

• Slow ~200 m walk → 0 stops; jittery dwell → 1 stop.
• No new failures on master (still the 20 known-backlog baseline — this breaks nothing).
• O(n) on a 16 000-sample walk (0.07→0.15→0.29→0.59 s, clean 2×/doubling).

Relationship to the cap (#62) — please read

This is the primary fix; the merge cap (#62) is defence-in-depth. Once walks are rejected at detection, they never reach the merge, so the cap rarely binds. They compose, with one caveat: #62 raised stop_radius_m in a few cap-geometry tests to force a chain to merge — but a raised radius makes that chain read as one progressive cluster, which this filter then rejects. So if you take both, those cap-geometry tests should be converted to call merge_nearby_stops directly (unit level) rather than routing a walk through /v1/insights. I kept this PR independent of #62 (branched from master) so you can review/merge them in either order; I'll reconcile the overlap once you've decided on #62.

Tunable to note

_PROGRESSIVE_DRIFT_FRACTION = 0.5 is a threshold worth your eye — it's the dwell-vs-walk sensitivity. 0.5 cleanly separates a directional radius-fill from jitter; lower rejects more aggressively. Could become an InsightsOptions knob if you want per-request control.