fix(quick-260921-oxm): STARTTLS wirklich erzwingen, Anhangs-Dateinamen richtig lesen

B-06: requireTLS durch doSTARTTLS ersetzt. requireTLS kennt imapflow 1.4.3
nicht und verwirft es still; ein als STARTTLS eingerichtetes Postfach konnte
deshalb unbemerkt im Klartext verbinden. Gewollte Folge: so ein Postfach
scheitert jetzt, wenn der Server kein STARTTLS anbietet. Bei ssl-tls ergibt
der Ausdruck false, was die Unvertraeglichkeit secure=true + doSTARTTLS=true
gar nicht erst entstehen laesst.

B-05: Dateiname aus Content-Disposition kommt jetzt aus dem Feld, in dem
imapflow ihn ablegt (dispositionParameters), statt aus .parameters einer
Zeichenkette. Der alte Ausdruck war zur Laufzeit immer undefined, wodurch
Anhaenge als application/octet-stream (typisch Outlook) nicht erkannt wurden.

Die Zusicherung am Ende von buildClient() entfaellt ersatzlos; sie bestand
nur wegen der unbekannten Option. noExplicitAny in apps/api/src faellt damit
von 15 auf 13.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TPPB4ApQxzSU1rwV2Ffj9J

apps/api/src/inbox/imap.provider.ts

@@ -62,20 +62,14 @@ function collectPdfParts(
   const type = node.type?.toLowerCase() ?? '';
   // Some mail clients (e.g. Outlook) send PDFs as application/octet-stream.
   // Fall back to checking the filename from Content-Disposition or Content-Type parameters.
-  // BLEIBT als any, mit Befund (260921-m34, Aufgabe 3c, D-01/D-03):
-  // imapflow deklariert `disposition` als ZEICHENKETTE (imap-flow.d.ts:448,
-  // also "attachment"/"inline"), und die zugehoerigen Parameter liegen in
-  // einem eigenen Feld `dispositionParameters` (:450). Der Ausdruck unten
-  // liest `.parameters` von einer Zeichenkette und ist damit zur Laufzeit
-  // IMMER undefined — dispositionFilename ist stets ''. Das ist ein Befund
-  // im Bestandscode, kein Typproblem: ihn hier auf `dispositionParameters`
-  // umzubiegen waere eine Verhaltensaenderung (Outlook-Anhaenge als
-  // application/octet-stream wuerden ab dann erstmals erkannt), und die ist
-  // in dieser Aufgabe verboten. Gemeldet im SUMMARY, Entscheidung beim
-  // Menschen. Die Zusicherung bleibt sichtbar stehen, damit der Befund
-  // nicht verschwindet.
-  const dispositionFilename =
-    ((node as any).disposition?.parameters?.filename as string | undefined)?.toLowerCase() ?? '';
+  // Repariert in 260921-oxm (Befund B-05 aus 260921-m34): hier stand zuvor
+  // `disposition?.parameters?.filename`, auf einem zu any umgedeuteten Knoten.
+  // imapflow deklariert `disposition` aber als ZEICHENKETTE (imap-flow.d.ts:448, also
+  // "attachment"/"inline") und legt die zugehoerigen Parameter in ein eigenes
+  // Feld `dispositionParameters` (:450, gefuellt in tools.js:887 mit
+  // kleingeschriebenen Schluesseln). Der alte Ausdruck las `.parameters` von
+  // einer Zeichenkette und war zur Laufzeit IMMER undefined.
+  const dispositionFilename = node.dispositionParameters?.filename?.toLowerCase() ?? '';
   // Hier dagegen war die Zusicherung schlicht ueberfluessig: imapflow
   // deklariert `parameters?: { [key: string]: string }` (imap-flow.d.ts:438).
   const typeFilename = node.parameters?.name?.toLowerCase() ?? '';
@@ -383,22 +377,21 @@ export class ImapProvider implements InboxProvider {
       port: config.port,
       // ssl-tls = implicit TLS (port 993); starttls = STARTTLS upgrade (port 143)
       secure: config.encryption === 'ssl-tls',
-      requireTLS: config.encryption === 'starttls',
+      // Repariert in 260921-oxm (Befund B-06 aus 260921-m34): hier stand zuvor
+      // `requireTLS`, eine Option, die imapflow 1.4.3 nirgends kennt und still
+      // verwirft. Die Bibliothek heisst sie `doSTARTTLS` (imap-flow.d.ts:81).
+      // true  -> vor der Anmeldung auf TLS hochstufen; scheitert, wenn der
+      //          Server kein STARTTLS anbietet (imap-flow.js:1183)
+      // false -> STARTTLS ausdruecklich aus (imap-flow.js:1210); bei ssl-tls
+      //          ist das noetig, weil secure=true zusammen mit
+      //          doSTARTTLS=true ungueltig waere (imap-flow.js:1201)
+      doSTARTTLS: config.encryption === 'starttls',
       auth:
         config.username
           ? { user: config.username, pass: config.password ?? '' }
           : undefined,
       // T-07-03: suppress imapflow verbose logs — they include auth credentials
       logger: false,
-      // BLEIBT als Zusicherung, mit Befund (260921-m34, Aufgabe 3c, D-03):
-      // `requireTLS` oben kommt in imapflow 1.4.3 NIRGENDS vor — weder in
-      // ImapFlowOptions (lib/imap-flow.d.ts) noch im Laufzeitcode
-      // (lib/imap-flow.js), beides durchsucht. Die Option wird also still
-      // verworfen; STARTTLS wird nicht durch sie erzwungen. Genau diese
-      // Zusicherung hat das bisher verdeckt. Sie bleibt trotzdem stehen:
-      // die Option zu entfernen waere eine stille Reparatur einer falschen
-      // Annahme (verboten), und der `any`-Befund haelt die Stelle in der
-      // Zaehlung sichtbar, bis ein Mensch entscheidet. Gemeldet im SUMMARY.
-    } as any);
+    });
   }
 }