refactor(structure): fix install export paths (WIP: layout/namespace plan)

[kcenon]

Closes #696

Status: DRAFT — build NOT verified locally

The ecosystem currently has a vcpkg-hash infrastructure failure (common_system v0.2.0)
that breaks local and CI C++ builds, and no CMake toolchain was available in the working
environment, so the changes here are CMake configure-graph fixes that could not be
compile- or configure-verified. This PR is opened as a draft for human review and to land
the audit-blocking install/export consistency fixes; the larger layout and namespace work
is described as a concrete plan below.

Root cause found

Two concrete, audit-blocking inconsistencies in the build/install configuration, both in
the "broken install paths" family from #696:

1. cmake/thread_system_install.cmake referenced non-existent directories.
   install_thread_system_headers() installed from interfaces/ and
   implementations/{thread_pool,typed_thread_pool,lockfree}/include/, none of which exist
   in the tree. The canonical public API actually lives entirely under
   include/kcenon/thread/... (129 headers), with thin forwarding-stub headers under
   core/base/include/, core/sync/include/, and utilities/include/ (verified to be
   deprecation shims that #include <kcenon/thread/...>, per the EPIC [EPIC] thread_system: absorb legacy directories into standard layout #683 window). The
   dangling install(DIRECTORY ...) entries corrupted the install/export surface that
   find_package(thread_system) depends on.

2. cmake/thread_system_targets.cmake was missing two alias targets. In-tree tests and
   examples link against thread_pool and typed_thread_pool, but
   create_thread_system_targets() only aliased thread_base, utilities, and
   interfaces to the unified thread_system library. A clean configure with tests
   enabled fails with target "thread_pool" not found. The installed package already
   promises thread_system::thread_pool / thread_system::typed_thread_pool via
   thread_system-config.cmake.in, so the in-tree graph was out of sync with the exported
   one.

Done (in this PR)

• cmake/thread_system_install.cmake — remove the dangling interfaces/ and
  implementations/.../include/ install rules; install the real public API from
  include/ recursively (now also matching *.hpp and *.tpp, so template
  implementations such as the typed_thread_pool .tpp files are exported, not only .h);
  install the still-present legacy forwarding stubs
  (core/base/include, core/sync/include, utilities/include) flat into the include
  prefix so old flat #include "thread_base.h" style usage keeps resolving during the
  EPIC [EPIC] thread_system: absorb legacy directories into standard layout #683 window, each guarded by EXISTS.
• cmake/thread_system_targets.cmake — add additive thread_pool and
  typed_thread_pool ALIAS targets to thread_system, so the in-tree target graph matches
  the installed export.

Both changes were checked for CMake syntax (balanced function/foreach/if, balanced
parentheses, no duplicated directives) but not compile/configure-verified (see Status).

Plan (deferred — needs build verification)

A. Stale build-only include dirs (same broken-path family)

~13 files under tests/unit/* and examples/* still add
${CMAKE_CURRENT_SOURCE_DIR}/../../implementations/<x>/include to
target_include_directories(...). These point at directories that no longer exist. A
compiler silently ignores a missing -I path, so they do not break the build, but they are
dead/misleading and should be removed once a configure run confirms each test/example still
finds its headers via the thread_system target's include/ interface.
Files: tests/unit/{thread_pool_test,typed_thread_pool_test,core_test,interfaces_test,thread_base_test,platform_test,diagnostics_test}/CMakeLists.txt,
examples/{composition_example,service_registry_sample,integration_example,multi_process_monitoring_integration}/CMakeLists.txt.

B. Layout unification (Problem 2: src/ vs top-level core/ + utilities/)

The tree mixes three source roots: include/kcenon/thread/... (canonical headers),
src/... (compiled .cpp, globbed by create_thread_system_targets()), and the legacy
stub roots core/{base,sync}/include + utilities/include. Pick one convention and apply
repo-wide:

• recommended: keep include/ + src/ as the single source of truth, then delete the
  core/ and utilities/ stub trees (and the install rules added here) at the end of the
  EPIC [EPIC] thread_system: absorb legacy directories into standard layout #683 deprecation window; or
• if core/ + utilities/ are meant to be first-class, move the canonical headers there
  and update the file(GLOB_RECURSE) roots, target_include_directories, and
  install(DIRECTORY ...) accordingly.
  Either path requires a configure+build to confirm no header is dropped.

C. Namespace migration to kcenon::thread (Problem 3)

This appears largely complete already: kcenon::thread is used in ~177 locations and there
are currently 0 uses of the legacy utility_module:: / thread_module:: /
thread_pool_module:: namespaces in include/, src/, core/, utilities/. Remaining
work: (1) confirm no legacy namespace aliases remain in headers, (2) decide whether to drop
the legacy CMake target aliases (thread_base, thread_pool, typed_thread_pool,
utilities, interfaces) and forwarding-stub headers at the end of the deprecation
window, and (3) align the install export NAMESPACE — the export currently uses
thread_system:: while the C++ namespace and the module target use kcenon::. Unifying
these is additive-then-removable but should be its own verified PR.

Risks

• Not compile/configure-verified (vcpkg-hash infra failure; no cmake in this
  environment). Reasoning is from the configure graph and the on-disk layout only.
• The legacy-stub install rules assume the stubs remain flat-includable; if a consumer
  expected them under a subdir, the destination may need adjustment (none observed in-tree).
• Plans A/B/C are intentionally deferred; no source files were moved and no layout changed
  in this PR.