Merge search/home/fit controls into the Plan/Fly header pill

Suche, Home- und Fit-Button sassen bisher in einer eigenen Leiste unter
der Plan/Fly-Kopfleiste - ein reiner UI-Kompromiss, weil die Karte
(inkl. MapController) in PlanScreen lebte und von der aeusseren
Kopfleiste aus nicht erreichbar war. Der HTML-Demonstrator zeigt
Suche/Home/Fit dagegen als Mittelteil derselben Leiste wie die
Modus-Buttons (#searchWrap/#homeBtn/#fitBtn in #topBarMiddle) - das war
also keine Stilfrage, sondern eine Datenfluss-Frage.

Loesung: MapController aus einem PlanScreen-privaten Feld in einen
app-lebenslangen mapControllerProvider (Riverpod) gehoben. Damit kann
die neue MapSearchControls (ersetzt TopNavBar) direkt in TopModeBar
eingebettet werden und lebt architektonisch dort, wo sie hingehoert:
bei der Kartensteuerung, nicht als Kind von PlanScreen.

Als Nebeneffekt - tatsaechlich der wichtigere Punkt - bleibt die
Kamera-Position/Zoom jetzt auch beim Wechsel Plan -> Fly -> Plan
erhalten. Verifiziert per flutter_map-Quellcode (FlutterMap haengt
einen extern uebergebenen Controller beim Neu-Mounten nicht an und
disposed ihn nicht) sowie per neuem Widget-Test, der den Cubit direkt
durch das Ready-to-Fly-Gate schickt (der Fly-Modus ist ueber die UI
aktuell nicht erreichbar, da Upload/Verify noch nicht implementiert
ist) und die Kamera vor/nach dem Wechsel vergleicht.

Zusaetzlich: _onMapEvent unterscheidet jetzt per MapEventMove.source,
ob eine Kartenbewegung programmatisch (mapController, z.B. durch Suche/
Home/Fit) oder per Geste ausgeloest wurde, und triggert den
Snap-to-Edit-Handler entsprechend nur bei Gesten bzw. sofort bei
programmatischen Moves - das ersetzt den bisherigen Ansatz, an jeder
Aufrufstelle manuell _handleMoveEnd() zu rufen, der nicht mehr skaliert
sobald diese Aufrufstellen (wie jetzt) in einem anderen Widget liegen.

Verifiziert: flutter analyze (0 issues), flutter test (22/22, inkl.
neuem Kamera-Persistenz-Test), manuell auf Pixel_10a-Emulator (Release-
Build) - Suche/Home/Fit erscheinen fusioniert in der gruenen Pille,
Kartenverschiebung bleibt nach Wechsel in den (durch das Gate weiterhin
blockierten) Fly-Modus sichtbar unveraendert.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

app/lib/ui/providers/map_controller_provider.dart

@@ -0,0 +1,22 @@
+import 'package:flutter_map/flutter_map.dart';
+import 'package:flutter_riverpod/flutter_riverpod.dart';
+
+/// Ein einziger, app-lebenslanger MapController statt einer pro
+/// PlanScreen-Mount neu erzeugten Instanz.
+///
+/// Grund: Die Kopfleiste (AppShell/TopModeBar) liegt eine Ebene ueber
+/// PlanScreen und braucht fuer Suche/Home/Fit denselben Controller wie die
+/// Karte - ein PlanScreen-privates Feld waere von dort nicht erreichbar.
+/// Als Nebeneffekt (und in Wahrheit der wichtigere Punkt) bleibt die
+/// Kamera-Position/Zoom jetzt auch ueber einen Wechsel nach Fly und
+/// zurueck erhalten: flutter_map tastet einen extern uebergebenen
+/// MapController beim erneuten Mounten nicht an (siehe
+/// FlutterMap._setMapController()), anders als der bisherige Zustand, wo
+/// PlanScreens eigener Controller beim Verlassen des Plan-Modus komplett
+/// verworfen wurde. Entspricht damit auch besser dem HTML-Demonstrator,
+/// der nur eine einzige Leaflet-Instanz fuer die gesamte App kennt.
+final mapControllerProvider = Provider<MapController>((ref) {
+  final controller = MapController();
+  ref.onDispose(controller.dispose);
+  return controller;
+});