fix(quick-261009-p0m): Abhaengigkeiten innerhalb der Hauptversionen aktualisiert, zwei unbenutzte entfernt

- Next.js 15.5.27, NestJS 11.2.7 (multer 2.4.0), nodemailer 9.1.1, undici 7.30.0 exakt, adm-zip 0.6.1, csv-parse 7.0.3, vitest (web) 4.1.11
- 15 pnpm-Overrides fuer mittelbare Bausteine, nur innerhalb derselben Hauptversion
- @nestjs-modules/mailer und ews-javascript-api entfernt (kein Import), Kommentare berichtigt
- Desktop: rustls 0.23.45 (mit rustls-webpki 0.103.15)
- pnpm audit --prod: 151 (5 kritisch, 73 hoch) -> 12 (0 kritisch, 9 hoch)
- Sicherheitsprotokoll, Entwicklungsanleitung und CHANGELOG nachgefuehrt

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

docs/anleitung-entwicklung.md

@@ -907,6 +907,35 @@ Code-Analyse). Die Regeln:
 - Jeder Eintrag in `.gitleaks.toml` trägt eine deutsche `description`, die sagt, warum es ein Fehlalarm ist.
 - Nie ganze Verzeichnisse außerhalb der Ordner mit Testdaten freigeben.
 
+### Abhängigkeiten aktualisieren
+
+Die Prüfung der Pipeline (`pnpm audit --prod`, osv-scanner, Trivy) meldet bekannte Schwachstellen in Bausteinen anderer
+Hersteller. So gehen Sie damit um:
+
+1. **Nur innerhalb der Hauptversion.** Patch- und Nebenstände werden angehoben, ein Sprung auf eine neue Hauptversion nie
+   nebenbei. Zurzeit gelten: Next.js 15, NestJS 11, React 19, Prisma exakt 6.19.3. Eine Meldung, deren Korrektur erst in einer
+   neuen Hauptversion liegt (heute zum Beispiel nodemailer 10 oder sharp 0.35), wird im Sicherheitsprotokoll als „offen“ mit
+   Grund geführt und nicht umgangen.
+2. **Direkte Abhängigkeiten werden angehoben, nicht überschrieben.** Steht der Baustein in einer `package.json`, ändern Sie
+   dort die Version (`pnpm --filter @tessera/api add paket@^x.y.z`). `undici` bleibt dabei **exakt** gepinnt, ohne `^`
+   (siehe die Dispatcher-Falle im Kapitel Konventionen).
+3. **Mittelbare Abhängigkeiten werden über `pnpm.overrides` angehoben.** Steckt der verwundbare Baustein tief in einem anderen
+   Paket, tragen Sie im Wurzel-`package.json` unter `pnpm` → `overrides` einen Eintrag der Form
+   `"name@>=4 <5": "^4.28.7"` ein: links die Versionslinie, die verwundbar ist, rechts die kleinste bereinigte Fassung.
+   Ein Eintrag gilt **nur innerhalb derselben Hauptversion** (bei Fassungen unter 1.0 derselben Nebenversion) und hebt nur die
+   verwundbare Linie an. Danach `pnpm install` und mit `pnpm why name` prüfen, dass nur noch bereinigte Fassungen übrig sind.
+4. **Jeder Override wird im Protokoll vermerkt** (Abschnitt „Verlauf“, Eintrag zur Aktualisierung) und **entfernt**, sobald das
+   übergeordnete Paket die bereinigte Fassung selbst mitbringt. Ein Override ist eine Überbrückung, kein Dauerzustand.
+5. **Neue Paketnamen brauchen einen bekannten Vater.** Vergleichen Sie die Paketnamen vor und nach der Aktualisierung in
+   `pnpm-lock.yaml`. Taucht ein Name auf, der vorher nicht da war, muss ein aktualisiertes Paket ihn selbst deklarieren
+   (`npm view paket@version dependencies optionalDependencies`). Ein Name ohne solchen Vater deutet auf einen unterschobenen
+   oder vertippten Baustein; die Aktualisierung, die ihn mitbrachte, wird zurückgenommen.
+6. **Prüfen Sie danach** `pnpm audit --prod` (vorher und nachher notieren), Typprüfung, Lint, beide Testläufe, den neu gebauten
+   lokalen Stack und die Rauchtests. Macht ein einzelner Baustein Probleme, nehmen Sie nur ihn zurück und führen ihn als
+   „offen“ mit Grund.
+7. **Die Desktop-App** hat eine eigene Paketliste (`apps/desktop/src-tauri/Cargo.lock`). Dort heben Sie einen Baustein mit
+   `cargo update -p name --precise x.y.z` innerhalb seiner Versionslinie an und prüfen mit `cargo check` und `cargo clippy`.
+
 ### Prüfung von außen (ZAP)
 
 Vor einer Freigabe wird alpha mit dem OWASP-ZAP-Abbild von außen angesehen (Ablauf: Betriebsanleitung, Kapitel 9, „Eine