Fix: Falsch benannte Hash-Manifeste löschen keine korrekten Dateien mehr

readHashManifest hat den pro Zeile korrekt erkannten Algorithmus mit dem aus der
DATEIENDUNG abgeleiteten überschrieben (.sfv→crc32, .md5→md5, .sha1→sha1).
parseHashLine erkennt den Algorithmus jedoch eindeutig an der Digest-Länge
(32-hex=MD5, 40-hex=SHA1, 8-hex=CRC32) — die Länge ist die verlässliche Quelle.
Stimmte die Endung nicht mit dem Zeileninhalt überein (z.B. eine MD5-Zeile in
einer .sfv-Datei), wurde der Algorithmus auf crc32 verbogen, hashFile berechnete
einen 8-Zeichen-CRC und verglich ihn mit dem 32-Zeichen-MD5 → garantiert
Mismatch. Folge: die intakte Datei wurde gelöscht, neu geladen, scheiterte
erneut und brach hart ab ("Integritätsprüfung fehlgeschlagen").

Fix: Den von parseHashLine erkannten Algorithmus übernehmen statt ihn per
Dateiendung zu überschreiben. Bei korrekt benannten Manifesten ist das ohnehin
ein No-op; nur die fehl-etikettierten Fälle werden repariert.

Test: .sfv-Datei mit MD5-formatierter Zeile + passende Datei → Algorithmus bleibt
MD5 und die Prüfung besteht. Mit der Endungs-Überschreibung wird crc32 erzwungen
und die gute Datei fällt durch (rot bewiesen).

src/main/integrity.ts

@@ -93,15 +93,11 @@ export function readHashManifest(packageDir: string): Map<string, ParsedHashEntr
       if (!parsed) {
         continue;
       }
-      const normalized: ParsedHashEntry = {
-        ...parsed,
-        algorithm: hit[1]
-      };
       const key = normalizeManifestKey(parsed.fileName);
       if (map.has(key)) {
         continue;
       }
-      map.set(key, normalized);
+      map.set(key, parsed);
     }
   }
   manifestCache.set(cacheKey, { at: Date.now(), entries: new Map(map) });