Phasenbasierte Lieferübersicht + Beladen-Flow, plus Migrationsplan für Rust-Backend

UI-Restructuring:
- TabBar in scan_page durch dedizierte Phasen ersetzt: Sortieren / Beladen / Ausliefern
- PhaseBloc + PhaseService leiten Phase aus Tour-/Item-States ab
- DeliverySelectionPage (ab 2 Autos) und DeliverySortPage als eigene Flows
- LoadingOverviewPage / LoadingCustomerPage für die Beladephase
- PhaseStepper-Widget im Home für Phasen-Anzeige
- Lager-Differenzierung (Standardlager 0 vs. Außenlager) via WarehouseBadge

Process-Stubs:
- ProcessRepository für Hold/Cancel/Sort/Assign-Flows (stub, bereit für Backend-Anbindung)

Doku:
- docs/BACKEND_MIGRATION.md: Phasenplan für Umstellung auf das neue
  Rust-Backend (OpenAPI-Generator, Keycloak OIDC, Clean-Arch-Layering)

lib/feature/delivery/bloc/tour_event.dart

@@ -37,6 +37,41 @@ class ReorderDeliveryEvent extends TourEvent {
   ReorderDeliveryEvent({required this.newPosition, required this.oldPosition, required this.carId});
 }
 
+/// Ersetzt die komplette Sortier-Information (z. B. beim Zurücksetzen auf
+/// die Default-Reihenfolge in der Sortier-Page). Persistiert lokal über
+/// den ReorderService, kein Backend-Call.
+class ReplaceSortingEvent extends TourEvent {
+  final String carId;
+  final Map<String, List<String>> newSortingInformation;
+
+  ReplaceSortingEvent({
+    required this.carId,
+    required this.newSortingInformation,
+  });
+}
+
+/// Bestätigung der Sortierung durch den Fahrer. Löst den (aktuell ge-
+/// stubbten) Backend-Call zur Persistierung der Reihenfolge aus und
+/// schaltet bei Erfolg in Phase [DeliveryPhase.beladen].
+class ConfirmSortingEvent extends TourEvent {
+  final String carId;
+
+  ConfirmSortingEvent({required this.carId});
+}
+
+/// Stellt sicher, dass der Sortier-Bucket für [carId] alle aktuell in der
+/// Tour vorhandenen Lieferungen enthält — und zwar UNABHÄNGIG von
+/// `delivery.carId`. Hintergrund: zum Sortier-Zeitpunkt sind die Lieferungen
+/// dem Fahrzeug oft noch nicht zugeordnet (das passiert erst beim Scannen
+/// während des Beladens). Der Fahrer hat aber bereits sein Tagesfahrzeug
+/// gewählt, also gehören alle Tour-Lieferungen in diesen Bucket. Bestehende
+/// Reihenfolge bleibt erhalten, fehlende IDs werden hinten angehängt.
+class EnsureSortingForCarEvent extends TourEvent {
+  final String carId;
+
+  EnsureSortingForCarEvent({required this.carId});
+}
+
 class TourUpdated extends TourEvent {
   Tour tour;
   List<Payment> payments;
@@ -63,6 +98,17 @@ class AssignCarEvent extends TourEvent {
   AssignCarEvent({required this.deliveryId, required this.carId});
 }
 
+/// Hebt die Fahrzeug-Zuordnung einer Lieferung wieder auf. Wird im
+/// Auswahl-Schritt ausgelöst, wenn der Fahrer eine eigene Lieferung
+/// "freigibt", damit ein Kollege sie übernehmen kann. Aktuell ruft der
+/// Handler nur den ProcessRepository-Stub auf — ein echtes Update der
+/// Tour erfolgt erst mit dem realen Backend-Endpoint (siehe Repository).
+class UnassignDeliveryEvent extends TourEvent {
+  final String deliveryId;
+
+  UnassignDeliveryEvent({required this.deliveryId});
+}
+
 class IncrementArticleScanAmount extends TourEvent {
   String internalArticleId;
   String deliveryId;