Give the V2X live map its own screen, and a traffic light per SPATEM

The map was a third view mode inside the V2X Monitor's topic pane, below
the use case alert panel and the DENM/CAM TX cards. On a phone that left
it about a third of the display tall, which is not enough to see where
anything is relative to anything else - the one thing a map is for. It
is now its own destination, V2xMapScreen on route v2x_map, reached from
a map button in that screen's header. The button sits in the header
rather than the view-mode row so it is also reachable from the message
detail pane and does not move as the available modes change with the
selected hardware. The status bar and bottom nav are hidden on this
route; the screen carries its own floating back button, and system back
still works. Both hardware paths get the same screen: everything drawn
comes from CamUseCaseRepository, which already merges the CiT One's MQTT
feed and the ESP32-C5's serial feed into one set of flows.

With the map gone from the toggle row, the row offers a single choice on
the ESP32-C5 path - there is no broker there and `topics` is always
empty - so it is hidden entirely in that mode.

SPATEM markers. Hazards already drew as a warning triangle; signalised
intersections did not draw at all. They now draw as a traffic light with
one lamp lit. Two things are worth knowing, because neither is forced by
the data:

- SPATEM carries signal state but no geometry, which is MAPEM's job and
  MAPEM is not decoded. The only position available is the sending RSU's
  own CAM, so the light is drawn there, and that RSU is drawn once - as
  the light, not as a CAM pin with a light on top of it. An intersection
  whose sender has not been heard over CAM cannot be placed; the map
  says how many rather than dropping them silently.
- Which lamp lights follows the rule DashboardScreen's SignalCard
  already uses, the signal group changing soonest speaking for the
  intersection, so the same intersection reads the same way in both
  places instead of inventing a second convention.

Four drawables rather than one tinted at runtime: setTint recolours
every path in a vector, so a single shared asset would turn the whole
light one flat colour and stop it reading as a traffic light.

Marker reuse. Every incoming message recomposes the map, and the update
block cleared the overlay list and rebuilt every Marker, decoding and
mutating a fresh Drawable per marker - at up to 10 Hz per station. It
also called animateTo(own) on every update, restarting the pan animation
before it could finish. Drawables are now loaded once per alert level
and phase and shared (osmdroid sets the icon's bounds on each draw, so
one instance across markers is safe), Markers are cached by key, and the
overlay list is only reordered, which moves references without
allocating. Following uses setCenter, keeping animateTo for the one move
worth seeing: the rider asking for follow back.

Follow-own now hands over to the rider on the first touch and returns
via the location button, which lights up while following. Before this
the map could not be panned at all while traffic was flowing, since the
next CAM dragged the viewport back.

Also on the map view: tiles scaled to DPI, the floating +/- buttons off
(they sit where the thumb lands and duplicate pinch), a zoom range, and
more tile threads so a pan that exposes a screenful of new tiles is not
served two at a time.

Compiles and the unit tests pass. None of it has been seen with live
traffic; TODO.md lists the on-device checks under "Waiting on hardware",
including which of the HAW RSUs send CAM alongside SPATEM.

TODO.md

@@ -5,6 +5,29 @@ Engineering to-do list. The reviewer-facing open items live in
 
 ## Waiting on hardware
 
+### On-device check of the full-screen V2X live map (added 2026-09-15)
+
+The live map moved out of the V2X Monitor's view-mode row into its own full-screen destination
+(`V2xMapScreen`, route `v2x_map`), reached from the map button in that screen's header. Markers are
+now cached and reused across updates instead of being rebuilt on every incoming message, and
+SPATEM intersections are drawn as traffic lights at the position of the RSU's own CAM. All of that
+compiles and the unit tests pass, but none of it has been seen with live traffic.
+
+Needs: the phone with the app, plus a CAM/DENM/SPATEM source - either the CiT One, or the OBU
+ESP32-C5 with a second board or a real RSU transmitting.
+
+- [ ] Both hardware modes: tap the map button, confirm the map fills the screen (no status bar, no
+      bottom nav) and the back button returns to the V2X Monitor.
+- [ ] Panning stays smooth while CAMs are arriving - this is what the marker reuse is for. Compare
+      against the old behaviour if it still judders.
+- [ ] Touching the map stops it recentring; the location FAB resumes follow and lights up.
+- [ ] A DENM shows the warning triangle, and a SPATEM intersection shows a traffic light with the
+      lamp matching the Dashboard's SignalCard for the same intersection.
+- [ ] Near a real RSU: confirm the RSU is drawn once, as a traffic light, not as a CAM pin with a
+      light on top of it. If the RSU sends SPATEM but no CAM, the "signals not shown" note should
+      appear instead - worth knowing which of the two the HAW RSUs actually do.
+
+
 ### Over-the-air check of the GN lifetime fix (added 2026-09-11)
 
 `geonet.c` now writes GN lifetime `0x05` (1 s) instead of `0x83`, which decoded to 3200 s. Changed