Phase 03: CAM decode coverage, real sensor data in TX, V2X monitor for ESP32 path

CAM codec:
- Stop rejecting CAMs carrying a specialVehicleContainer. It is declared last in
  CamParameters, after everything this decoder reads, so buses / emergency
  vehicles / road-works vehicles now decode for position and kinematics instead
  of being dropped outright
- Drop the lowFrequencyContainer parse - it extracted nothing into Cam, and its
  reads were only correct when no high-frequency optionals were present
- Document why the 7 optional-presence bits are consumed but not acted on: UPER
  writes a SEQUENCE's presence bitmap up front but each field's value in
  declaration order, and all seven are declared after yawRate
- Field widths and container ordering verified against the ETSI ASN.1 sources in
  the C-ITS-Parser checkout, not from memory

Transmit path:
- Own StationID is now a persisted random 32-bit value instead of a hardcoded 0.
  Receivers key on StationID to track a station across CAMs, so every unit
  broadcasting 0 made two MicrOBUs indistinguishable - including to this app's
  own detection engine
- Populate longitudinalAcceleration from successive GNSS speed samples. Not from
  the accelerometer: CAM wants signed along-track acceleration, and the raw
  sensor is device-frame with gravity in it. Null outside a usable sample gap
  rather than a fabricated value
- CAM pinger builds from live GNSS/IMU via PhoneCamBuilder instead of beaconing a
  hardcoded bench coordinate with speed and heading pinned to zero, so it now
  exercises the sensor pipeline and not just the wire. Sends nothing without a
  fix, and reports that rather than sitting at "Sent: 0"

V2X monitor:
- Received-CAM pane for the ESP32-C5 path, replacing the MQTT topic list that is
  permanently empty there. One row per station rather than per message - CAMs
  arrive at 1-10 Hz per station, so the pane is bounded by road users nearby, not
  by traffic rate. Nearest first, tinted by active alert level
- DENM hazard pins on the live map as a warning triangle, drawn above vehicle
  markers. CiT One path only: the ESP32 firmware forwards BTP-B port 2001 (CAM)
  and drops port 2002 before it reaches the phone

DenmParser uses tolerant field-name matching - the Use Case API's DENM JSON
schema is not yet confirmed against real payloads.

app/src/main/res/drawable/ic_denm_warning.xml

@@ -0,0 +1,31 @@
+<!--
+  DENM map pin: the standard hazard warning triangle (! in a triangle).
+
+  Drawn rather than reused from Material's Icons.Filled.Warning because osmdroid Markers take a
+  Drawable, not a Compose ImageVector, and a filled triangle with an opaque outline reads far
+  better against arbitrary map tiles than a single-colour glyph does.
+-->
+<vector xmlns:android="http://schemas.android.com/apk/res/android"
+    android:width="36dp"
+    android:height="36dp"
+    android:viewportWidth="24"
+    android:viewportHeight="24">
+
+    <!-- White outline first, so the pin stays legible over dark map features. -->
+    <path
+        android:fillColor="#FFFFFFFF"
+        android:pathData="M12,1.2L0.6,21.4h22.8L12,1.2z" />
+
+    <!-- Amber triangle body. -->
+    <path
+        android:fillColor="#FFFFC107"
+        android:pathData="M12,3.6L2.9,20.0h18.2L12,3.6z" />
+
+    <!-- Exclamation mark. -->
+    <path
+        android:fillColor="#FF1A1A1A"
+        android:pathData="M11.1,8.4h1.8v5.4h-1.8z" />
+    <path
+        android:fillColor="#FF1A1A1A"
+        android:pathData="M11.1,15.2h1.8v1.8h-1.8z" />
+</vector>