Fix Windows-Konsolen-Encoding für Log-Ausgaben (UTF-8 vs. CP850)

- log4j2.xml: charset="UTF-8" explizit auf beiden PatternLayout-Elementen
  (Console + RollingFile), damit Log4j2 unabhängig vom JVM-Standard UTF-8
  schreibt
- Batch-Dateien: chcp 65001 vor dem EXE-Aufruf, damit die Windows-Konsole
  die UTF-8-Bytes korrekt anzeigt
- docs/betrieb.md: neuer Abschnitt "Konsolen-Encoding unter Windows" mit
  Hinweis auf chcp 65001 und -Dstdout.encoding=UTF-8 für den direkten
  Standalone-JAR-Start

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

docs/betrieb.md

@@ -102,6 +102,28 @@ java -jar pdf-umbenenner-bootstrap/target/pdf-umbenenner-bootstrap-0.0.1-SNAPSHO
 Die Anwendung liest die Konfiguration standardmäßig aus `config/application.properties` relativ zum
 Arbeitsverzeichnis, in dem der Befehl ausgeführt wird.
 
+### Konsolen-Encoding unter Windows
+
+Die Anwendung schreibt alle Log-Ausgaben in UTF-8. Windows-Konsolen (PowerShell, CMD) verwenden
+standardmäßig den OEM-Codepage (z. B. CP850), was zu unlesbaren Sonderzeichen führt.
+
+**Lösung:** Konsole vor dem Start auf UTF-8 umschalten:
+
+```
+chcp 65001
+java -jar pdf-umbenenner-bootstrap-*.jar --headless
+```
+
+Alternativ kann die UTF-8-Ausgabe auch als JVM-Argument angegeben werden (Java 17+):
+
+```
+java -Dstdout.encoding=UTF-8 -jar pdf-umbenenner-bootstrap-*.jar --headless
+```
+
+> **Hinweis:** Die mitgelieferten Batch-Dateien (`PDF-KI-Renamer.bat`, `PDF-KI-Renamer-GUI.bat`)
+> rufen `chcp 65001` automatisch auf. Der Windows Task Scheduler schreibt Log-Ausgaben in eine
+> Protokolldatei, die stets UTF-8-kodiert ist – dort entsteht kein Anzeigeproblem.
+
 ### Start über Windows Task Scheduler
 
 Empfohlene Startsequenz für den headless Betrieb über den Windows Task Scheduler: