Summary

Migrate logger_system's thread_system integration from direct dependency to using common_system's IExecutor interface as a neutral abstraction layer.

Parent Issue

• deps: Resolve bidirectional thread_system dependency risk #252

Background

Issue #252 identified two approaches for resolving bidirectional dependency risk:

• Option A (Implemented in deps: Resolve bidirectional thread_system dependency risk #252): CMake conflict detection + documentation
• Option B (This Issue): Use IExecutor as neutral dependency

This issue implements Option B for a cleaner architectural solution.

Current State

// Current: Direct thread_system dependency
#include <kcenon/thread/core/thread_pool.h>

class async_logger {
    std::shared_ptr<kcenon::thread::thread_pool> pool_;
};

Proposed Solution

// Proposed: Use IExecutor interface from common_system
#include <kcenon/common/interfaces/executor.h>

class async_logger {
public:
    explicit async_logger(std::shared_ptr<common::interfaces::IExecutor> executor)
        : executor_(std::move(executor)) {}

    void log(const log_entry& entry) {
        executor_->execute([this, entry] {
            write_to_backend(entry);
        });
    }

private:
    std::shared_ptr<common::interfaces::IExecutor> executor_;
};

Benefits

1. No compile-time dependency between logger and thread_system
2. Neutral abstraction - common_system is already required by both
3. Flexibility - Users can provide custom executors
4. Testability - Mock executors for unit testing
5. Future-proof - Can swap executor implementations

Tasks

• Verify IExecutor interface exists in common_system (or create if needed)
• Create thread_pool executor adapter in thread_system
• Update thread_integration_detector.h to check for IExecutor
• Modify thread_system_integration class to use IExecutor
• Create standalone executor wrapper for std::jthread
• Update tests to use executor injection
• Update documentation

Acceptance Criteria

• logger_system compiles without direct thread_system headers
• Runtime executor injection works correctly
• Performance is comparable to direct integration
• Tests pass with both standalone and thread_pool executors
• Documentation updated with executor patterns

Priority

MEDIUM - Architectural improvement, not blocking production use

Related

• deps: Resolve bidirectional thread_system dependency risk #252 (parent issue)
• Epic: Cross-Module Circular Dependency Resolution common_system#232 (ecosystem integration epic)