Implement Parallel Test Execution

[hawkeyexl]

Summary

Implement configurable parallel test execution in Doc Detective to enable users to run multiple test contexts concurrently, reducing overall test suite execution time while maintaining backward compatibility.

Background

Currently, Doc Detective executes all test contexts sequentially. This creates bottlenecks for large test suites or tests with wait times. Users need the ability to run multiple tests in parallel to improve development velocity and CI/CD pipeline efficiency.

Requirements

Configuration Options

• concurrentRunners: 1 (default) - Sequential execution (current behavior)
• concurrentRunners: true - Automatic parallel execution using Math.min(os.cpus().length, 4)
• concurrentRunners: <integer> - Explicit number of concurrent runners (no artificial cap)

Technical Constraints

• Tests within a single context remain sequential (only test contexts run in parallel)
• Maintain test isolation - no cross-test interference
• Preserve existing error handling and reporting
• No performance regression for default sequential behavior

Success Criteria

• Configuration schema accepts integer ≥1 and boolean values
• Default behavior unchanged (sequential execution)
• Boolean true resolves to CPU cores capped at 4
• Explicit integers respected without caps
• Parallel execution reduces test suite time
• Test isolation maintained
• Error handling works in parallel mode

Implementation Plan

This feature requires changes across three repositories:

1. doc-detective-common (#XXX): Update configuration schema
2. doc-detective-resolver (#XXX): Add configuration resolution logic
3. doc-detective-core (#XXX): Implement parallel execution engine

Dependencies

• Issue #XXX (common schema changes) must be completed first
• Issue #XXX (resolver changes) depends on common completion
• Issue #XXX (core changes) depends on both common and resolver completion

Testing Strategy

• Unit tests for configuration resolution logic
• Integration tests for parallel execution with various concurrency levels
• Performance benchmarking to validate execution time improvements
• Isolation testing to ensure no cross-test interference

Risk Mitigation

• Conservative defaults prevent resource exhaustion
• Opt-in nature preserves existing workflows
• Clear documentation about test independence requirements