What

Complete the Result error handling migration by replacing the remaining 15 throw statements in 6 source files with Result return types. The public API migration is already complete (#952); this covers the internal implementation layer.

Why

• Inconsistent error handling: public APIs return Result but internal code still throws
• Exception-based code in adapters creates unhandled exception risk when called from Result-based code
• Ecosystem standard: all kcenon libraries use Result from common_system
• Priority: Medium — public API is already migrated, but internal consistency matters

Where

Files with remaining throw statements (15 total)

Integration bridges (8 throws, 3 files)

• src/integration/thread_pool_bridge.cpp — 2 throws (constructor, from_common_system)
• src/integration/observability_bridge.cpp — 4 throws (constructor, from_common_system)
• src/integration/thread_system_adapter.cpp — 1 throw (constructor)

Internal adapters (4 throws, 1 file)

• src/internal/integration/thread_pool_adapters.h — 4 throws (constructors, execute/execute_delayed lambdas)

Protocol implementation (2 throws, 1 file)

• src/internal/dtls_socket.cpp — 2 throws (SSL/BIO creation failures)

Utility (1 throw, 1 file)

• src/internal/utils/message_validator.h — 1 throw (validate_size_or_throw)

How

Technical Approach

1. Bridges/adapters: Convert constructors from throwing to factory functions returning Result<BridgeType>
   • ThreadPoolBridge::create(pool) -> Result<ThreadPoolBridge> pattern
2. DTLS socket: Convert constructor to factory, return error Result on SSL/BIO failure
3. Message validator: Rename validate_size_or_throw() to validate_size() returning Result<void>
4. Lambda throws: Replace with Result return or error callback pattern

Acceptance Criteria

• Zero throw statements in src/ (excluding test code)
• All call sites updated to handle Result returns
• No behavior changes for success paths
• Existing tests continue to pass
• New tests verify error paths return correct error codes