fix(PROJ-73): Upload-Job-Status bei Panic + nil-Guards nach GetByUsername

Upload-Job bleibt bei einem Panic im Verarbeitungspfad nicht mehr auf
"running" hängen, sondern zeigt "error" mit generischer Meldung (Panic-
Rohwert nur im Server-Log, ErrMsg geht ans Frontend und könnte sonst
Mail-Inhalt-Fragmente transportieren). Zusätzlich fail-closed nil-Guards
an allen 13 GetByUsername-Aufrufstellen in internal/api/, die das
Ergebnis bisher ungeprüft dereferenzierten.

Verifiziert auf 192.168.1.132: Build und go vet fehlerfrei für die
geänderten Dateien.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019j28kGcaJAhBnrYX34hGdt

internal/api/upload.go

@@ -145,6 +145,21 @@ func (s *Server) handleUploadProgress(w http.ResponseWriter, r *http.Request) {
 func (s *Server) runUploadJob(job *UploadJob, messages [][]byte, tenantID *int64) {
 	ctx := context.Background()
 
+	// PROJ-73: a panic in the import path must not leave the job stuck on
+	// "running" forever — surface it as an error state in the upload UI.
+	// safego.Go still catches the panic afterwards for the stack trace log.
+	defer func() {
+		if rec := recover(); rec != nil {
+			job.mu.Lock()
+			job.Status = "error"
+			// No panic value in the message: it can carry mail content
+			// fragments (DSGVO). Details go to the log via safego.Run.
+			job.ErrMsg = "Import wegen eines internen Fehlers abgebrochen"
+			job.mu.Unlock()
+			panic(rec)
+		}
+	}()
+
 	for _, raw := range messages {
 		result := s.importRawMessage(ctx, raw, tenantID)
 		job.mu.Lock()