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).
Strip every comment from the source (parsed with the TypeScript compiler so
strings, template literals, regex literals and JSX are never touched), and drop
internal/working artifacts that do not belong in the public repository
(design mockups, internal analysis docs, a stray backup file and an old log).
No functional change: build is green, the full test suite passes.
