Bundle Qt6Sql via windeployqt on Windows installer

[AhmedAredah]

Summary

The Windows installer ships a bin/ folder that is missing Qt6Sql.dll (and the matching sqldrivers/qsqlite.dll plugin). Running terminal_simulation.exe from a freshly installed copy fails immediately with exit code -1073741515 / 0xC0000135 (STATUS_DLL_NOT_FOUND).

Root cause

installer/deploy/deploy_windows.cmake invokes windeployqt against terminal_simulation.exe only. windeployqt follows the Qt imports of the binaries it is pointed at — nothing else. The main executable imports Qt6Core and Qt6Network; Qt6Sql is pulled in transitively by Container.dll (SQLite-backed container store). windeployqt never sees Container.dll, so Qt6Sql.dll and its sqldrivers/ plugin are never copied into the installer payload.

Verified locally against a v0.1.x Windows installer:

terminal_simulation.exe imports: Qt6Core.dll, Qt6Network.dll
Container.dll          imports: Qt6Core.dll, Qt6Sql.dll   <-- missing from bundle

Fix

Pass the installed Container.dll to windeployqt as a second positional input. windeployqt 6.6+ accepts multiple binaries and emits the union of their Qt closures, which pulls in Qt6Sql.dll plus sqldrivers/qsqlite.dll.

The install(FILES ...) for Container.dll already runs before this install(CODE ...) block, so the installed copy is on disk by the time windeployqt is invoked.

Why Linux/macOS are not changed

• Linux (deploy_linux.cmake) already enumerates Qt6::Sql explicitly in its bundled-modules list, and the install-time ldd closure walk would catch libContainer.so -> libQt6Sql.so regardless. The script's own comments cite this exact case.
• macOS (deploy_macos.cmake) runs macdeployqt against the bundle root, which scans every binary already inside the bundle (including the relocated Container dylib) — the same transitive-resolution issue does not apply.

Test plan

• Re-run the Release workflow (or push a tag) and confirm the produced TerminalSim-*-windows-x64.exe payload contains bin/Qt6Sql.dll and bin/sqldrivers/qsqlite.dll.
• Install on a clean Windows 10/11 host (no Qt SDK present) and run bin\terminal_simulation.exe — it should start and reach the RabbitMQ connect/wait state instead of exiting with 0xC0000135.
• Confirm Linux release still builds and runs (no behavioral change expected).