Stop retaining detected manoeuvres; the CAM rate bump is their only consumer

The detector runs to raise the CAM transmit rate through a manoeuvre. Nothing
else read its output once the UI was removed, so keeping the rows was storing
data with no reader on the chance it would one day be analysed.

Drops the detected_events table in schema v5, deletes DetectedEventEntity and
the DAO and repository methods behind it, removes the insertEvent call from the
recording service, and removes the per-event rows and their five columns
(event_type, confidence, peak_accel, peak_gyro, duration_ms) from the trip CSV
along with the events parameter threaded through buildTripCsv and shareTripCsv.
A detected manoeuvre now lives for the length of one onDetectedEvent call.

MIGRATION_1_2 still creates the table: a v1 install upgrades 1-2-3-4-5 and so
creates it before v5 drops it. Removing it from the earlier migration would
break that path for anyone who has not upgraded yet.

trips.eventCount is kept. Dropping a SQLite column means recreating the table
and copying every recorded ride across, which is real risk for one unused
integer; the service still writes an accurate count and the CSV header still
reports it. It is the only thing left about detected manoeuvres.

This closes off the route to the false-positive measurement that 11.3 flags as
missing, so 11.3 now says that outright rather than pointing at an export that
no longer carries the data. Docs 11.3/11.4, the user guide, the README and the
traceability matrix updated to match. 55 tests, 0 failures.

docs/01-requirements-traceability.md

@@ -139,7 +139,7 @@ share no code. The requirement is satisfied twice, by different means.
 | 11.1 | Orientation-Independent Sensor Strategy | **Done** | `SensorRepository.kt` (magnitude-based) | — |
 | 11.2 | Running Standard Deviation Event Detector | **Done** | `EventDetector.kt`, `RunningStats.kt` | **18 unit tests, 0 failures** |
 | 11.3 | Trip Recording Architecture | **Done** | `TripRepository.kt`, `TripRecordingService.kt` *(cited)* | — |
-| 11.4 | Data Model | **Done** | `data/db/` Room entities *(cited)* | — |
+| 11.4 | Data Model | **Partial — scope reduced** | `data/db/` Room entities *(cited)* | `detected_events` dropped in schema v5, see scope note |
 | 11.5 | New UI Elements for Phase A | **Partial — scope reduced** | `TripHistoryScreen.kt`, `TripReviewScreen.kt` | event pins/counters removed by decision, see note |
 | 11.6 | Phase A Success Criteria | **Partial** | — | needs a real ride; see Open Items |
 
@@ -154,7 +154,10 @@ the coloured event pins and detail sheet on the trip review map, and the event c
 history card — was removed deliberately. A count of the rider's own braking events is not a goal of
 this project. The detector itself still runs: it is the input to the CAM transmit-rate policy
 (§ 13), which raises the beacon rate from 1 Hz to the elevated rate for five seconds after a
-detected manoeuvre. Events remain persisted and exported to CSV for offline analysis.
+detected manoeuvre. That is now its only effect: the `detected_events` table was dropped in schema
+v5 and the per-event rows removed from the trip CSV, so a detected manoeuvre is consumed and
+discarded. `trips.eventCount` is kept as a single integer per ride, since dropping a SQLite column
+means recreating the table.
 
 **Defect note (11.2).** Two defects found while documenting the detector were fixed on 2026-09-07.
 The nine threshold overrides in `TripRecordingService`'s constructor were promoted to