fix(PROJ-81): BUG-81-5/-6 - AC1-Wortlaut angeglichen, Content-Type-Fallback für endungslose Anhänge

- AC1-Text auf tatsächlichen Vorschau-Button-Ansatz umformuliert
- resolveMimeType(): Server-content_type nur als Hinweis bei fehlender
  Dateiendung, kann vorhandene Endung nicht überstimmen; Rendering bleibt
  strikt auf clientseitige MIME-Whitelist beschränkt (Security-Modell
  unverändert, kein SVG/HTML)

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

features/PROJ-81-anhang-online-vorschau.md

@@ -17,7 +17,7 @@ Mail-Anhänge lassen sich in `/mail/[id]` aktuell nur herunterladen (`downloadMa
 - Als Admin/Auditor will ich, dass Vorschau nur für Anhänge funktioniert, auf die der jeweilige Tenant/User laut bestehender Zugriffsregeln berechtigt ist (keine neue Sicherheitslücke).
 
 ## Acceptance Criteria
-- [ ] Klick auf Anhang öffnet Vorschau als Modal/Dialog über der aktuellen Mail-Ansicht
+- [ ] Jede Anhang-Zeile hat einen eigenen "Vorschau"-Button, der die Vorschau als Modal/Dialog über der aktuellen Mail-Ansicht öffnet (bewusst ein separater Button statt Klick auf die ganze Zeile, damit "Vorschau" und "Herunterladen" eindeutig unterscheidbar bleiben — siehe BUG-81-5)
 - [ ] PDF-Anhänge werden inline gerendert (Browser-natives PDF-Rendering oder eingebetteter Viewer)
 - [ ] Bild-Anhänge (jpg, png, gif, webp) werden als Bildvorschau angezeigt
 - [ ] Nicht unterstützte Dateitypen (inkl. Office-Dokumente wie docx/xlsx) zeigen Hinweis "Keine Vorschau verfügbar" + Download-Button bleibt erhalten
@@ -240,13 +240,32 @@ Der Grund für den Guard steht als Kommentar direkt am Effekt, damit er bei kün
 ### BUG-81-4 (Low) — Sicherheitskommentar widersprach dem Code — **fixed**
 Der Datei-Header behauptete "sandboxed iframe ohne allow-same-origin/allow-scripts", tatsächlich ist `sandbox="allow-scripts"` gesetzt. Header korrigiert: `allow-scripts` **ja**, `allow-same-origin` **nein** (undurchsichtiger Origin, kein Cookie-/DOM-Zugriff), inkl. Begründung warum `allow-scripts` nötig ist. Ein falscher Security-Kommentar ist gefährlich, weil künftige Reviews darauf vertrauen — daher trotz Low-Severity sofort mitgenommen.
 
+### BUG-81-5 (Low) — AC1-Wortlaut vs. Umsetzung — **fixed (Spec-Text)**
+Kein Code-Fix. AC1 oben umformuliert: statt "Klick auf Anhang öffnet Vorschau" beschreibt es jetzt den tatsächlich umgesetzten separaten "Vorschau"-Button je Anhang-Zeile, inkl. Begründung (Vorschau und Herunterladen bleiben eindeutig unterscheidbar). Spec und Code stimmen damit überein.
+
+### BUG-81-6 (Low) — Anhänge ohne Dateiendung bekamen nie Vorschau — **fixed**
+`AttachmentPreviewDialog.tsx`: Die Typ-Erkennung läuft jetzt über `resolveMimeType()`:
+1. Dateiendung `pdf` bzw. bekannte Bild-Endung → gewinnt weiterhin, unverändert.
+2. **Nur bei komplett fehlender Endung** (`scan`, `Rechnung` — typisch für Fax-/Scanner-Gateways) wird der Server-`content_type` als Hinweis herangezogen, über die neue Konstante `ALLOWED_MIME_TYPES` (Parameter wie `; charset=…` werden abgeschnitten, Vergleich case-insensitiv).
+3. Unbekannte Endung → weiterhin "keine Vorschau"; der Server-Wert kann eine vorhandene Endung **nicht** überstimmen.
+
+**Das Security-Modell bleibt unverändert:** der Server-Wert entscheidet ausschließlich, *welcher* Eintrag aus der festen Whitelist gewählt wird. Gerendert wird nach wie vor nur mit dem clientseitig erzwungenen MIME-Typ aus dieser Liste. Ein Wert außerhalb der Whitelist — insbesondere `image/svg+xml` (PROJ-61-Vektor) oder `text/html` — führt zu "keine Vorschau", nicht zum Rendern. SVG ist in `ALLOWED_MIME_TYPES` bewusst nicht enthalten.
+Ein Angreifer gewinnt dadurch nichts: er könnte über den Content-Type höchstens erreichen, dass seine endungslose Datei als PDF oder Bild *interpretiert* wird — genau die beiden Pfade, die ohnehin als sicher ausgelegt sind (erzwungener MIME-Typ, PDF im Sandbox-iframe ohne `allow-same-origin`).
+
 ### Offen, wie abgestimmt (kein Code-Fix in diesem Durchgang)
 - **BUG-81-3** — PDF-Sandbox in Firefox/Safari unbelegt: nach Deploy im Browser verifizieren. Fällt das Rendering aus, braucht es einen sichtbaren Hinweis statt eines leeren weißen Rahmens.
-- **BUG-81-5** (AC1-Wortlaut "Klick auf Anhang" vs. Vorschau-Button) und **BUG-81-6** (Anhänge ohne Dateiendung bekommen keinen Vorschau-Button) — nicht angefasst.
 - **Audit-Logging für Anhang-Abrufe** (Bestandsfund aus dem Security-Audit): bewusst **nicht** hier mitgefixt, bekommt ein eigenes Ticket.
 - Die drei Backend-Fragen sind vom QA-Lauf beantwortet (nosniff nur über nginx, `Content-Disposition: attachment` gesetzt, **keine** serverseitige Content-Type-Whitelist). Für die Vorschau unkritisch, weil der Dialog den Server-Content-Type ignoriert; die empfohlene Handler-seitige Härtung ist Backend-Scope.
 
 Nach den Fixes: `npx tsc --noEmit` und `npm run build` fehlerfrei.
 
+### Stand nach zweitem Fix-Durchgang
+Alle im QA-Bericht gemeldeten Bugs sind erledigt: BUG-81-1 (High/Blocker), BUG-81-2 (Medium), BUG-81-4 (Low), BUG-81-5 (Low, Spec-Text), BUG-81-6 (Low). Offen bleibt allein **BUG-81-3** — die PDF-Darstellung im Sandbox-iframe ist für Firefox und Safari unbelegt und lässt sich nur im echten Browser gegen eine laufende Instanz prüfen.
+
+**Deployment-Empfehlung: deploybar auf 132.** Kein offener Blocker im Code. Der Status bleibt bewusst auf **In Review** und geht erst auf Deployed, wenn nach dem Deploy verifiziert ist:
+- BUG-81-3: PDF-Vorschau in Chrome, Firefox, Safari, Edge. Rendert ein Browser nichts, braucht es einen sichtbaren Hinweis statt eines leeren weißen Rahmens.
+- Gegenprobe zu BUG-81-1: fehlgeschlagene Vorschau (z.B. 404) erzeugt genau **einen** Request, keine Schleife — im Netzwerk-Tab prüfen.
+- Gegenprobe zu BUG-81-6: endungsloser PDF-Anhang bekommt einen Vorschau-Button und rendert.
+
 ## Deployment
 _To be added by /deploy_