CPack COMPONENT split: services vs Qt install targets

CPack today packages everything on Linux as a single DEB with CPACK_COMPONENTS_GROUPING ALL_COMPONENTS_IN_ONE (build/cpack/CMakeLists.txt), and none of the ~97 install(TARGETS ...) call sites across projects/*/CMakeLists.txt tag a COMPONENT. Splitting into a services component (everything except the ores.qt/* subprojects) and a qt component (the 16 ores.qt/* CMakeLists.txt) would let CPack produce a services-only archive, avoiding Qt6 runtime/dev bulk on headless deploy targets. This requires classifying and editing each of the ~97 call sites by hand (no shared install macro/function exists to centralise this), plus adding component-based CPack config (CPACK_COMPONENTS_ALL=/=CPACK_INSTALL_CMAKE_PROJECTS or turning off ALL_COMPONENTS_IN_ONE). Before doing the sweep, confirm none of these CMakeLists.txt files are codegen-generated/templated (no .j2 templates were found for them, but worth double-checking with the codegen skills) — a bulk hand-edit would otherwise be silently undone on next regeneration.

Surfaced while scoping deploy packaging for the "Offload service and DB runtime to a WSL host over SSH" story: the target host is a bare service runtime (no GUI), and today the only reusable packaging primitive (cmake --install / CPack DEB) carries the full desktop client along for the ride. A component split would make the eventual package genuinely minimal, but is a wide mechanical sweep, not a quick fix — out of scope for the current analysis task.

• build/cpack/CMakeLists.txt — CPack config, ALL_COMPONENTS_IN_ONE on Linux.
• projects/ores.qt/*/CMakeLists.txt (16 files) — candidate qt component.

• Offload service and DB runtime to a WSL host over SSH (story)
• Analyse approach for offloading services/DB to a WSL host (task)