feat(a3): Fehlermeldungen inline, verstaendlich, loesungsorientiert

[TBum1404]

Ticket A3 – Fehlermeldungen inline, verständlich, lösungsorientiert

Umsetzung nach Design-Template „Wizard Error Handling", gegengecheckt mit 01_Results/fehlerklassen-ableitbarkeit.html und fehlerbehandlung-wizard-analyse.html. Enthält auch die Persistent-Result-Fixes aus A11 (P-S5-02/03).

Was gemacht

• Ursachen-Fix: Worker-Fehler werden als echte Error statt bloßer String verworfen (data-processor.ts), damit die echte Ursache den instanceof Error-Check überlebt; clearError() gegen den beim Wiedereinstieg klebenden Fehler.
• Neues Fehlerklassen-Modell shared/constants/wizard-error-classes.ts (K1–K6) mit WHY/FIX/Zielschritt; Fallback für unbekannte Rohfehler; Hintergrund-Fehler → verwerfbare Warnungen.
• Wiederverwendbare Issue-Karte shared/wizard-issue-card/ (Schweregrad-Icon, Klassen-Badge, WHY/FIX, einklappbare technische Details, „Fix in Schritt N"-Button, optional Dismiss).
• Step 5: persistenter Statusscreen mit fünf Zuständen (Review+Pre-flight, Processing, blockierender Fehler, Partial, Success), „Your work is saved"-Pill, Methoden-Statusleiste, „Fix in Schritt N"-Sprung über die A6-Logik + Toast; ngOnInit stellt Ergebnis/Fehler nach Wiedereinstieg wieder her (P-S5-02/03).
• Step 4: feldnahe Inline-Validierung (rote Meldung direkt unter den Nachbar-Parametern bei K4; Glyph-Panel flaggt „zu viele" >12).

Manuelle Testschritte (Schritt → Location → Erwartung)

• CSV laden, Step 4 UMAP-Nachbarn ≥ Zeilenzahl, verarbeiten → Step 5: roter Hero + K4-Karte + „Fix in Schritt 4" springt zu Methoden mit Toast.
• Hintergrund-Methode scheitern lassen, FastMap ok → grünes Banner + amber „N von M" + verwerfbare Karte; Dismiss entfernt sie.
• Step 4 UMAP-Params, Nachbarn über Zeilenzahl → Inline-Fehler direkt unter dem Feld.
• Nach Fehler Wizard schließen + neu öffnen → Step 5 zeigt weiterhin den klassifizierten Fehler (kein Leerscreen); nach Erfolg + Neuöffnen → Ergebnis wiederhergestellt.
• Konstante/fast leere Spalte in der Projektion behalten → Review: amber Pre-flight-Banner + „Possible issue"-Karte.

Build: npm run build erfolgreich (nur vorbestehende Bundle-Budget-Warnung).

[TBum1404]

• fehler ist sehr kryptisch, das kann der nutzer nicht lesen

- wenn ich "try again" clicke, blinkt die ui nur kurz auf, es sieht nicht so aus, als würde etwas passieren. Ich denke dass der Retry nocht stattgefunden hat. Es sollte einen tooltip geben der ausgelöst wird, wenn wirklich retried wird. - Da wir playright schon haben, macht es sinn entweder einen e2e test oder unit/komponententests zu schreiben (ggf. mit einer anderen bibliothek), damit wir das erwartete Verhalten durch diese tests sichern können. Ich kann nicht alle cases manuell testen. - wenn es erfolgreich war, sollte trotzdem die try again methode verfügbar sein

[TBum1404]

ready to merge