Phase C+D-1: Cars-Domain auf Rust-Backend umgestellt

Clean-Arch-Schichten für Cars:
- lib/domain/entity/car.dart: UUID-id, accountId (Personalnummer),
  plate, active. Pendant zum Backend-Schema.
- lib/domain/repository/cars_repository.dart: Port — listMine,
  create, update. Keine teamId/personalnummer-Parameter, der
  Account fließt serverseitig aus dem JWT.
- lib/data/mapper/car_mapper.dart: API-DTO (built_value) → Domain.
- lib/data/repository/cars_repository_impl.dart: konkrete Impl via
  generierter CarsApi (dio), mit DioException → CarsRepositoryException-
  Übersetzung.

Feature-Cars-Refactoring:
- CarsBloc nimmt jetzt die Domain-Repository-Schnittstelle. Events:
  CarLoad/CarAdd/CarEdit/CarDeactivate (statt CarDelete). Keine
  teamId-Parameter mehr. Kein authBloc-Bezug, Session-Expiry läuft
  über den globalen Provider-Stream.
- CarsState sealed mit CarsInitial/Loading/LoadingFailed/Loaded.
- Pages: car_management_page, car_management, car_card, car_fail_page,
  car_selection_page komplett auf die neue Entity und Event-Signaturen.
- Alte lib/feature/cars/service/cars_service.dart und
  lib/feature/cars/repository/cars_repository.dart gelöscht.

CarSelectBloc + Storage:
- CarSelection.selectedCarId von int? auf String? umgestellt.
- CarSelectionRepository persistiert die UUID jetzt als String;
  defensive Migration für noch vorhandene int-Werte (alte
  Pre-Migration-Installations) verwirft den Wert leise und
  erzwingt Neuauswahl.

Konsequenz-Cleanup im Tour-Code (Phase-D-Vorbereitung):
- Delivery.carId String? statt int?.
- Tour.hasUndeliveredLoadedArticles / getFinishedDeliveries auf
  String carId.
- _selectedCarId / int? carId / int selectedCarId in DeliveryOverview,
  LoadingCustomerPage/OverviewPage, Home, DeliverySelection/SortPage,
  DeliveryInfo/List, CustomSortDialog, SortableDeliveryList auf
  String umgestellt.
- TourRepository ersetzt int.parse(carId)/int.tryParse-Zuweisungen
  direkt durch String.
- lib/model/car.dart wird zum Re-Export der neuen Domain-Entity,
  damit Legacy-Imports während Phase-D-Übergang weiter compilieren.

DI:
- app.dart: CarsBloc bekommt CarsRepositoryImpl(locator<HolzleitnerApi>())
  statt der alten CarsRepository(service: CarService()).

Build (flutter build apk --debug) durch, flutter analyze ohne
errors.

lib/domain/repository/cars_repository.dart

@@ -0,0 +1,43 @@
+import 'package:hl_lieferservice/domain/entity/car.dart';
+
+/// Port für Fahrzeug-Stammdaten des angemeldeten Fahrers.
+///
+/// Bewusst **kein** `personalnummer`/`teamId`-Parameter: der Account
+/// wird serverseitig aus dem JWT abgeleitet, der Client muss nichts
+/// mitschicken. Eine Methode, die einen Account-Filter ermöglicht,
+/// ist konsequent nicht vorgesehen.
+///
+/// Implementierungen werfen anwendungs-spezifische Exceptions
+/// (z. B. `CarsRepositoryException`) — der Aufrufer fängt sie und
+/// übersetzt in UI-Zustand.
+abstract interface class CarsRepository {
+  /// Liste der Fahrzeuge des angemeldeten Accounts.
+  /// `includeInactive=false` blendet deaktivierte Fahrzeuge aus
+  /// (Default für die App-UI).
+  Future<List<Car>> listMine({bool includeInactive = false});
+
+  /// Legt ein neues Fahrzeug mit dem gegebenen Kennzeichen an.
+  /// Wirft, wenn das Kennzeichen für den Account schon existiert.
+  Future<Car> create({required String plate});
+
+  /// Aktualisiert ein bestehendes Fahrzeug.
+  /// Beide Optional-Parameter `null` ist ein No-Op-PATCH.
+  /// Soft-Delete erfolgt über `update(carId: ..., active: false)`.
+  Future<Car> update({
+    required String carId,
+    String? plate,
+    bool? active,
+  });
+}
+
+/// Allgemeine Repository-Exception. Konkrete Implementierungen
+/// können spezifischere Subtypen werfen (z. B. `CarsUnauthorized`).
+class CarsRepositoryException implements Exception {
+  const CarsRepositoryException(this.message, [this.cause]);
+
+  final String message;
+  final Object? cause;
+
+  @override
+  String toString() => 'CarsRepositoryException: $message';
+}