Add Android Auto support

[ekodikara]

Add Android Auto support

Shows MeshMapper's Map tab on Android Auto head units, so a wardriving session can be followed and controlled from the car screen.

Relates to MeshMapper/MeshMapper_Project#411

What it does

• Map: the car draws its own MapLibre map with the user's map style, the vector coverage overlay with the same palette and opacity as the phone, the session's freshly patched cells, recently heard repeaters, and the position arrow. It follows the car heading up by default; the centre button re-centres after a pan and switches between heading up and north up.
• Status: a card at the top left shows the phase with a live countdown ("Next disc 13s"), and the TX, RX, discovery, trace and upload counters. It keeps a steady width as phases change. A box at the top right shows the noise floor and companion battery, like the phone header.
• Controls: Start Passive or Stop, Ping, map style, and a More screen (with a back arrow to the map) holding the other start modes and the recently heard list. Pan and zoom work from touch and from a rotary dial in pan mode.

How it works

• The car is a remote for the session on the phone; it never talks to the radio, GPS or API itself.
• It renders the existing Siri snapshot projection plus a map block over a new meshmapper/android_auto channel. Snapshots are only published while a car is connected, so phones that never meet a car pay one early return per notify.
• Every car tap becomes an ExternalSessionCommand with a new androidAuto source and goes through admitExternalSessionCommand and executeExternalSessionCommand, the same checks as the phone buttons, the watch and Siri. A stale car screen cannot transmit anything the phone would refuse.
• The coverage tile URL and the map style URLs move into shared helpers (coverage_tile_url.dart, map_style_urls.dart) so the phone map and the car map cannot drift apart. The phone map behaves exactly as before.
• No new third party dependency beyond the Android for Cars App Library (androidx.car.app:app:1.4.0). Details are in the new Android Auto section of DEVELOPMENT.md.

Things for maintainers to decide

• App category. Drawing a custom map needs the NAVIGATION category. Play only lists real turn by turn apps there, so a public release needs either Google's approval for this use or a switch to the POI category with a host drawn map (pins only, no coverage overlay).
• Relation to Add an Android Auto Surface #31. Add an Android Auto Surface #31 takes a similar surface approach as a POI app through flutter_carplay. This PR is an alternative based on current dev: about 2,800 lines across 35 files, no new Flutter dependency, and it reuses the watch and Siri command path. Happy to combine efforts or rework this around whatever direction you prefer.

How to test

1. Build and install a debug build on an Android phone.
2. In Android Auto settings, tap the version number ten times, then in Developer settings enable Unknown sources and start the head unit server.
3. Run adb forward tcp:5277 tcp:5277 and the Desktop Head Unit, open MeshMapper on the phone, connect a companion, and open MeshMapper in the head unit.
4. A real car only lists apps installed from Play, so in car testing needs a Play internal testing build.

Tested on a Galaxy Z Fold6 with the Desktop Head Unit, and in a Mazda through a Play internal testing build.

Checks

• flutter analyze: no issues.
• flutter test: all tests pass, including new tests for the bridge and the car map projection.
• dart format is clean for every file this PR adds. CI's format step already fails on dev for files this PR does not touch, so that check will show the same pre-existing failure.

Screenshots

(Screenshots of the car screen: the map with the status card and battery box, the Start/Stop/Ping buttons, and the More screen.)

[MrAlders0n]

Discord post from a few weeks ago:

https://discord.com/channels/1463383723327356992/1494771314207101072/1551583779515277313