```text
Setze die Qt5->Qt6-Migration fort und bearbeite strikt nur die ./files.txt aufgelisteten Stub-Dateien im Qt6-Baum.

Ausgangslage:
- die ./files.txt aufgelisteten Dateien wurden während der Migration als STUBS erzeugt
- die Migration ist noch nicht abgeschlossen
- /workspace/app/Dockerfile ist der Migrationscontainer
- /workspace/qt-migration-legatus/qt6-after/qt6-migrated-legatus/docker_build.sh ist der Validierungscontainer nach einem Migrationsschritt

Ziel:
- verschiebe die ./files.txt aufgelisteten Stub-/Forward-Declaration-Dateien physisch in ein gemeinsames Verzeichnis:
  - /workspace/qt-migration-legatus/qt6-after/qt6-migrated-legatus/forward-declarations
- passe danach die direkt betroffenen Includes und CMake-Build-Skripte minimal so an, dass ausschließlich diese neue physische Ablage verwendet wird

Wichtige Klarstellung:
- es geht ausdrücklich um **physisches Verschieben**
- keine Wrapper-Header
- keine Weiterleitungs-Header
- keine Kopien
- keine Duplikate
- keine parallele Alt-/Neu-Struktur
- keine Kompatibilitätslayer
- keine Symlinks
- kein Belassen der bisherigen Stub-Dateien an den alten Orten

Harte Regeln:
- nur die ./files.txt aufgelisteten Stub-Dateien bearbeiten
- keine Refactorings
- keine opportunistischen Fixes
- keine fachlogischen Änderungen
- keine Änderungen im Legacy-Tree
- keine neuen Stubs erzeugen
- keine neuen Placeholder-Dateien erzeugen
- keine Scheinlösung über zusätzliche Include-Pfade, die alte und neue Orte gleichzeitig sichtbar machen
- Build und Includes sollen deterministisch nur noch gegen die neue Struktur arbeiten

Pflichtanalyse:
- prüfe jede aufgelistete Datei darauf, ob sie tatsächlich ein Stub-/Forward-Declaration-Artefakt ist
- falls einzelne gelistete Dateien doch keine solchen Artefakte sind, verschiebe sie nicht blind, sondern dokumentiere sie als Ausnahmen
- identifiziere Redundanzen und Mehrfachablagen
- bestimme die minimal nötigen Include-Anpassungen nach dem physischen Verschieben
- bestimme die minimal nötigen CMake-Anpassungen nach dem physischen Verschieben

Pflichtumsetzung:
- verschiebe die betroffenen Dateien physisch nach:
 - /workspace/qt-migration-legatus/qt6-after/qt6-migrated-legatus/forward-declarations
- bereinige die alten Pfade so, dass keine alten Stub-Dateien zurückbleiben
- passe alle direkt betroffenen `#include`-Stellen minimal an
- passe alle direkt betroffenen `CMakeLists.txt` / cmake-Include-Pfade minimal an
- stelle sicher, dass die neue Struktur im Build korrekt und eindeutig referenziert wird

Strikte Include-/CMake-Regeln:
- bevorzuge zielbezogene Include-Pfade mit `target_include_directories(...)`
- vermeide globale `include_directories(...)`, außer wenn das bestehende Buildsystem es an genau dieser Stelle zwingend verlangt
- füge nicht gleichzeitig alte und neue Stub-Verzeichnisse in Include-Pfade ein
- keine Workarounds durch künstliche Suchreihenfolgen
- keine Pfadverdopplungen
- keine implizite Altpfad-Kompatibilität
- nur direkt betroffene Build-Skripte ändern

Validierung:
- nutze /workspace/qt-migration-legatus/qt6-after/qt6-migrated-legatus/docker_build.sh als Validierungsweg
- passe das Script nur an, wenn für diese Aufgabe zwingend nötig
- führe mindestens Configure + Build im Docker-Kontext aus
- prüfe, dass die Builds die Dateien tatsächlich aus `forward-declarations` konsumieren
- prüfe, dass kein Build-Erfolg mehr von den alten Pfaden abhängt
- falls sinnvoll, nutze gezielte Target-Builds zusätzlich zur Gesamtvalidierung

Erfolgskriterien:
- die betroffenen Stub-/Forward-Declaration-Dateien wurden physisch nach
  - /workspace/qt-migration-legatus/qt6-after/qt6-migrated-legatus/forward-declarations
  verschoben
- die alten Stub-Dateien liegen nicht mehr an den bisherigen Pfaden
- Includes und CMake-Skripte sind minimal angepasst
- der Build referenziert deterministisch die neue Struktur
- keine Wrapper-/Redirect-/Kompatibilitätsheader
- keine Duplikate
- keine unnötigen Moduländerungen
- keine vorgetäuschte Validierung

Wenn etwas nicht sauber möglich ist:
- nicht mit Wrappern oder Kopien ausweichen
- nicht stillschweigend beide Strukturen parallel behalten
- als teilweise validiert oder blockiert melden
- exakten technischen Blocker benennen

Abschlussbericht nur kurz:
- validiert, teilweise validiert oder blockiert
- physisch verschobene Dateien
- geänderte Include-Stellen
- geänderte CMake-Dateien
- exakte Docker-Kommandos
- verbleibende Blocker oder Risiken
```