Make the event detector a CAM rate input, not a ride-stats readout

The detector's only live consumer is the CAM transmit-rate policy: every
emitted event calls CamTransmitLoop.onDetectedEvent, raising the beacon
rate from 1 Hz to the elevated rate for five seconds so nearby stations
get denser updates through a manoeuvre. Counting one's own braking events
is not a goal of this project, so the display is gone and the detector
stays: the live per-type counters and their notification text, the event
pins and detail sheet on the trip review map, and the event chip on the
history card. Events are still persisted and exported to CSV, which is
the only route to the tuning measurement section 11.3 says is missing.

Fix two defects found while documenting the detector.

TripRecordingService overrode nine of DetectionConfig's twelve parameters
in its constructor, so the tests validated the Phase A defaults while the
phone ran something materially less sensitive. The tuned values are now
the defaults and the override is deleted; the numbers moved location, not
value, so detector sensitivity is unchanged. EventDetectorTest now sets
only windowSize and the sustained-frame counts and inherits every signal
threshold, which cannot drift again. That was not a free change and makes
the same point from the other side: at the real thresholds the old stimuli
triggered nothing. Accel alternating 3.5/0.5 gives a std dev of 1.5 and
never clears 1.8, and the moderate-braking case used a 0.8 m/s drop that
never clears 1.0. Those stimuli are re-derived against the real values.

brakingHighConfidenceRate was documented as a rate but has always been
compared against the peak cumulative drop from the onset speed, which
grows with episode length, so HIGH was assigned more readily than the name
implied. Renamed to brakingHighConfidencePeakDrop rather than changing the
comparison: "lost more than 1.5 m/s in one episode" is coherent, whereas a
rate off a 1 Hz speed signal sampled at 50 Hz spikes on a near-zero
divisor early in an episode. Output is unchanged, so the existing
confidence assertions stay evidence instead of being re-baselined.

Docs 11.3/11.4 updated in place, including the correction of a claim that
detected events do not reach the V2X side; the rate-bump path already
existed when that was written. 55 tests, 0 failures.

docs/01-requirements-traceability.md

@@ -140,7 +140,7 @@ share no code. The requirement is satisfied twice, by different means.
 | 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.5 | New UI Elements for Phase A | **Done** | `TripHistoryScreen.kt`, `TripReviewScreen.kt` | — |
+| 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 |
 
 **Correction note (11.2).** Four `EventDetectorTest` cases had been failing since the initial commit.
@@ -149,6 +149,23 @@ described stimuli the detector cannot physically see, because they ignored the s
 rolling standard-deviation window. Tests corrected, assertions unchanged, detector untouched. This is
 worth reporting — it is a finding about test design, not a defect.
 
+**Scope note (11.5).** The event-detection UI — the live per-type counters on the recording screen,
+the coloured event pins and detail sheet on the trip review map, and the event count on the trip
+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.
+
+**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
+`DetectionConfig`'s defaults and the override deleted, so there is one configuration and
+`EventDetectorTest` exercises the shipping thresholds rather than the superseded Phase A ones;
+detector sensitivity is unchanged, and the synthetic stimuli were re-derived because several no
+longer cleared the stricter real thresholds. `brakingHighConfidenceRate` was renamed
+`brakingHighConfidencePeakDrop`: it was documented as a rate but has always been compared against
+the peak cumulative speed drop. The name was corrected rather than the comparison, so detector
+output is unchanged and the confidence assertions remain valid evidence.
+
 ## 12. Future Architecture & Open Design Questions
 
 | § | Title | Status | Notes |