Namensentschlüsselung, Phase 4 PUT, Bridge-Fix, Debug-Tools

- name-decrypt.js: AES-Entschlüsselung für Datei-/Ordnernamen (CRYPTO_SECRET2)
- path-resolver.js: getPlainName für alle Pfad-Operationen
- upload.js: PUT mit Verschlüsselung, Bridge API v2
- download.js: Bridge 400-Fix (x-api-version, Header)
- debug-name-decrypt.js: Test-Skript für Namensentschlüsselung
- docs: CRYPTO_SECRET/CRYPTO_SECRET2 dokumentiert

Made-with: Cursor

docs/webdav-architektur.md

@@ -52,12 +52,12 @@ Die drive-web nutzt `Network.client` (Bridge) und `NetworkFacade` für Up-/Downl
 
 1. **Phase 1:** PROPFIND (Verzeichnis auflisten) – ✅ implementiert
 2. **Phase 2:** MKCOL, DELETE, MOVE – ✅ implementiert
-3. **Phase 3:** GET (Download) – Bridge + Entschlüsselung
-4. **Phase 4:** PUT (Upload) – Verschlüsselung + Bridge
+3. **Phase 3:** GET (Download) – Bridge + Entschlüsselung – ✅ implementiert
+4. **Phase 4:** PUT (Upload) – Verschlüsselung + Bridge – ✅ implementiert
 
-### Hinweis: Ordnernamen
+### Namensentschlüsselung
 
-Internxt nutzt Zero-Knowledge-Verschlüsselung. Die API liefert verschlüsselte Namen (`name`). Die Pfadauflösung funktioniert, weil WebDAV-URLs diese Namen enthalten. Eine spätere Phase kann Namensentschlüsselung mit Mnemonic ergänzen (drive-web Crypto-Logik).
+Internxt nutzt Zero-Knowledge-Verschlüsselung. Die API liefert verschlüsselte Namen (`name`). Wenn `plain_name` fehlt, kann der Server mit `CRYPTO_SECRET2` (oder `CRYPTO_SECRET`) Namen entschlüsseln – analog zur drive-web `aes.decrypt`-Logik mit `secret2-parentId`/`secret2-folderId`. Ohne gesetztes Secret werden die rohen (verschlüsselten) Namen verwendet.
 
 ## Token vs. Bridge-Credentials