Follows the removal of logos-cpp-generator --provider-header. Nothing in the
workspace passed PROVIDER_HEADER to logos_module().
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* Link modules against logos-qt-sdk + logos-protocol (Qt split)
The SDK stack split: logos-cpp-sdk is now the Qt-free header-only base
(detected via logos_module_context.h and linked as
logos-cpp-sdk::logos_headers), the Qt developer layer (LogosAPI,
provider glue, legacy PluginInterface) lives in logos-qt-sdk, and the
transports + lp_* C ABI live in logos-protocol.
logos_module() now resolves LOGOS_QT_SDK_ROOT / LOGOS_PROTOCOL_ROOT
(env / CMake var / sibling checkout), links
logos-qt-sdk::logos_qt_sdk (which chains logos-protocol and its
OpenSSL/Boost/nlohmann link interface), and adds the new include roots.
Source-layout builds compile qt-sdk's sources into the plugin and take
logos-protocol installed or as a subproject.
* cmake: compile the generated universal-UI glue into the plugin
type=ui_qml + interface=universal backends get their plugin class
(Q_PLUGIN_METADATA + initLogos wiring) generated into generated_code/ by
logos-qt-generator — this copy of LogosModule.cmake only picked up
logos_sdk.cpp, so the built dylib had no Qt plugin metadata at all
('Failed to extract plugin meta data'). Scoped append (not a broad glob)
so the provider-dispatch handling below can't double-compile.
