docs(PROJ-84,PROJ-85): Status auf Deployed - Backfill/Reindex auf 131+132 verifiziert

PROJ-84: 131 hatte 0 Kandidaten, 132 541/541 korrigiert (bereits
vorher bestätigt). PROJ-85: --apply + reindex auf 132 (54/54) und
131 (Produktiv) ohne Fehler durchgelaufen, User-Gegenprobe bestätigt.

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

features/PROJ-85-fix-undeklarierte-8bit-header-charset.md

@@ -1,6 +1,6 @@
 # PROJ-85: Fix undeklarierte 8-Bit-Zeichen in Header/Body ohne Encoded-Word
 
-## Status: In Review
+## Status: Deployed
 **Created:** 2026-08-06
 **Last Updated:** 2026-08-06
 
@@ -24,8 +24,8 @@ Beim Scan wurde daneben aber ein echter archivmail-Bug gefunden, verschieden von
 - [x] Body-Decoding (Single-Part und Multipart, alle Content-Type-Fehlerpfade) wendet dieselbe Reparatur an, außer bei binären Attachments (`Attachment.Data` bleibt byte-exakt)
 - [x] `fix-subjects`-Kommando erkennt zusätzlich zu Encoded-Word-Fällen (PROJ-84) auch rohe 8-Bit-Subjects ohne Encoded-Word-Marker (`NeedsCharsetRepair`)
 - [x] Tests decken ab: gültiges UTF-8 bleibt unangetastet, Windows-1252-Sonderzeichen (ä/ö/ü/ß/–/®) werden korrekt repariert
-- [ ] `--apply` auf 132 durchgeführt, danach `archivmail reindex` für Body-Korrektur
-- [ ] `--apply` + `reindex` auf 131 (Produktiv), Umfang dort separat messen (131 ≠ 132, siehe PROJ-84-Erfahrung: 0 vs. 543 Kandidaten)
+- [x] `--apply` auf 132 durchgeführt (54/54 aktualisiert, 0 Fehler), danach `archivmail reindex` für Body-Korrektur (User-Gegenprobe bestätigt, 2026-08-06)
+- [x] `--apply` + `reindex` auf 131 (Produktiv) durchgeführt, ohne Fehler (2026-08-06)
 
 ## Edge Cases
 - Encoded-Word mit RFC-5322-widriger Syntax (Leerzeichen im codierten Teil) → bleibt unverändert, als „undecodable" gezählt, nicht Teil dieses Fixes (schon in PROJ-84 als Grenzfall dokumentiert)