feat: limit in-flight operations in map/parallel

[yaythomas]

Description of changes:
max_concurrency previously sized the thread pool only, so branches that suspended (invoke, wait, callbacks) released their thread and the next item started immediately. All items were initiated at once regardless of the configured limit.

Rework the concurrency executor around a single coordinator loop:

• The calling thread owns all branch state and schedules work; worker threads only run branches and report outcomes on a queue. No locks remain in the module.
• max_concurrency now bounds in-flight branches. A suspended branch keeps its slot until it reaches a terminal state, matching the JS and Java SDKs. When every in-flight branch is suspended, the parent suspends with the earliest resume timestamp, or indefinitely.
• Branches start in index order and operation ids derive from the branch index, so scheduling stays deterministic across invocations.
• Timed suspends resume in-process via the event queue timeout, replacing the TimerScheduler background thread.
• Consolidate completion logic (thresholds and reason inference) into CompletionPolicy, replacing ExecutionCounters and the duplicated logic in BatchResult.
• Omit never-started branches from BatchResult, matching the JS SDK.
• Stop scheduling when a branch is orphaned: an ancestor completed, so all further checkpoints under it would be rejected.
• Validate config bounds at construction, matching the Java SDK: max_concurrency and min_successful must be at least 1, tolerated_failure_count non-negative, tolerated_failure_percentage within 0-100. Previously max_concurrency=0 silently meant unlimited and min_successful=0 silently meant all items.

Issue #, if available:
Closes #279

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.