Refresh the Flutter snapshot: v3 tickets V3-04 through V3-16, plus a fresh installable APK

V3-04 through V3-07, V3-10, V3-16 shipped complete; V3-11/V3-12/V3-14 shipped code-complete pending device/account verification; V3-08/V3-09 deferred behind a new V3-17 (self-hosted OSRM investigation). 316 tests passing, up from 221.

The APK is a fresh release build (debug-signed, no release signing config exists yet) with two build fixes applied: core library desugaring enabled for flutter_local_notifications, and sentry_flutter bumped to 9.27.0 (8.14.2's bundled Kotlin plugin was incompatible with this project's Kotlin 2.4.0 toolchain).

rippr-flutter-src/docs/v3/V3-15-auto-pause.md

@@ -0,0 +1,57 @@
+# V3-15 — Auto-pause
+
+**Phase** Quality · **Depends on** V3-13 · **Size** M · **Status** Gated on evidence
+
+## Goal
+Decide — with data — whether the app should pause itself when the rider stops.
+
+## Context
+**Rejected in v2 as unreliable in traffic**, and that reasoning still stands: a motorcycle
+at a long red light is stationary and still mid-ride. Auto-pausing there fragments a ride
+into dozens of segments and makes the map look wrong.
+
+Kept in the backlog because it is a common expectation from other ride apps.
+
+## The gate
+**Do not build this until V3-13 provides real ride data**, then answer:
+
+1. How long is a typical traffic stop, versus a real break?
+2. Is there a clean threshold between them, or do the distributions overlap?
+3. Does moving time already handle this well enough? The noise floor **already excludes
+   stationary time from moving time** — so the numbers may be right and only the segment
+   count would change.
+
+**If (3) is true, this ticket should be closed rather than built.** That is a legitimate
+outcome and arguably the likely one.
+
+## Design, if the data supports it
+Time-based, not motion-based: pause after N minutes below the noise floor, resume on the
+first fix above it. N derived from the data, not guessed, and never below two minutes.
+
+Off by default, in settings, described plainly.
+
+## Implementation
+1. Analyse stop-duration distribution from real rides
+2. **Decide and record whether to proceed**
+3. If proceeding: a threshold in `RecordingEngine`, reusing the existing pause path so
+   segments behave identically to a manual pause
+4. Setting, defaulting off
+
+## Acceptance criteria
+- [ ] A written decision, with the data behind it
+- [ ] If built: a traffic-light stop does **not** pause; a coffee stop does
+- [ ] Auto-pause produces segments indistinguishable from manual ones
+- [ ] Off by default
+
+## Tests
+- Synthetic stop patterns: short stop stays recording, long stop pauses
+- An auto-paused ride's segments behave exactly like manual ones
+- Distance still never spans the gap
+
+## Risks
+Building it because other apps have it, rather than because the data says so. The gate
+exists for that reason.
+
+## Out of scope
+Motion-sensor detection. That is the paid-engine feature set, and this app deliberately
+does not use it.