refactor(build): decompose CMakeLists.txt into cmake/ modules

[kcenon]

What

Decompose the 743-line top-level CMakeLists.txt into per-concern modules under cmake/, leaving the root file as a 49-line orchestrator.

Module map

Module	Responsibility
cmake/options.cmake	option() declarations and feature toggles
cmake/compile_options.cmake	language standards, output dirs, warning helpers
cmake/dependencies.cmake	Threads + common_system imported target wiring
cmake/sources.cmake	source/header file lists
cmake/targets.cmake	add_library(container_system) + flags + defs + links
cmake/modules.cmake	optional C++20 module library target
cmake/test.cmake	unit / integration / fuzz registration
cmake/documentation.cmake	Doxygen target wiring
cmake/samples.cmake	samples / examples / benchmarks subdirectories
cmake/install.cmake	install rules + package config generation
cmake/summary.cmake	end-of-configure status print

Existing cmake/UnifiedDependencies.cmake, cmake/Version.cmake, cmake/container_system-config.cmake.in, and cmake/toolchain-arm64-linux.cmake are unchanged.

Why

A 743-line top-level CMakeLists is hard to review and prone to merge conflicts every time options/dependencies/install rules change. Sibling repos in the EPIC already use a per-concern cmake-module layout. Aligning container_system removes a recurring friction point for cross-repo refactors and makes future changes scoped.

How

Behaviour parity

The mechanical relocation preserves every install destination, component, pattern filter, compile flag, definition, and target alias verbatim from the legacy file. No options were added, removed, or renamed. No build artefact name changes. The Doxygen layout and install layout review remain owned by issue #536.

Two helper functions extracted

• apply_container_compile_options(<target>) (in cmake/compile_options.cmake) bundles the warning suppressions, standard warning set, Clang-specific tweaks, and Windows definitions into a single reusable hook. The static library target consumes it from cmake/targets.cmake. The C++20 module target in cmake/modules.cmake does not currently call it (matching legacy behaviour) but the helper is available if a future change wants identical flags applied there too.
• apply_container_simd_definitions(<target>) (in cmake/compile_options.cmake) detects compiler SIMD support and applies HAS_AVX2 / HAS_SSE42 / HAS_ARM_NEON private compile definitions. It re-exports COMPILER_SUPPORTS_AVX2 and COMPILER_SUPPORTS_SSE42 to the parent scope so cmake/summary.cmake can read the detection results without re-running the checks.
• configure_container_common_system_dep(<target>) (in cmake/dependencies.cmake) encapsulates the unified_find_dependency(common_system) call plus the kcenon::common_system imported INTERFACE target creation, with the same inline copy-properties logic the legacy file used.

Acceptance Criteria

• Top-level CMakeLists.txt ≤ ~80 lines (49 lines after refactor, was 743)
• Every concern in its own cmake/<area>.cmake
• cmake -S . -B build && cmake --build build succeeds (verified via CI — local toolchain unavailable in sandbox)
• ctest passes (verified via CI)
• install still produces the same export layout (no destinations or rules changed; verified by reading the diff)

Test Plan

• CI must pass on every platform.
• The mechanical nature of this refactor means the test signal is the build itself: if the build configures, links, and tests pass identically to the prior CI run on develop, behaviour parity is confirmed.
• An install-layout diff was not run locally because the sandbox does not have CMake or a C++ toolchain installed; this is acceptable per workflow/ci-resilience.md (toolchain fallback).

Closes #535
Part of #531