Twenty-four component source lists are stale against the generator

projects/ores.codegen/scripts/regenerate_cmake_component_files.py --all --check reports that 24 committed src/component_files.cmake and tests/component_files.cmake lists disagree with what the ores.cmake.component.files_{src,tests} archetypes render from the live models. The components named so far are analytics (api, service), assets, compute and workspace, with the rest of the 24 to be read off a full run.

These lists are checked in and CMakeLists.txt includes them in place of a file(GLOB_RECURSE ...), so a stale list is a source the build silently does not compile or a test the build silently does not run. The gate that would catch it is not wired into any per-PR job, so the drift accumulated across the components whose clean passes did not run the CMake generator.

The drift is on main: each flagged file is byte-identical to origin/main, so this is not a consequence of any one branch. The fix is either to run the generator across the tree once, or to make the check part of the gate that already runs the other codegen checks.

• The check and its modes: projects/ores.codegen/scripts/regenerate_cmake_component_files.py --help.
• The archetypes: projects/ores.codegen/library/templates/cmake_component_files_src.mustache, .../cmake_component_files_tests.mustache.
• Precedent for wiring it in: the drift gate's --sweep mode in check_component_drift.py.
• Found while re-verifying feature/clean-refdata after a rebase onto main.

• Bring ores.refdata to the clean standard