Summary

This PR makes RunConfig.disable_early_shutdown=True forcibly disable the early-shutdown mechanism (no indirect threshold tricks). When disabled, we still collect error metrics/summaries, but we will never:

• flip early_shutdown=true,
• shut down the executor early, or
• raise the "terminated early due to error rate" exception.

Background / Findings (root cause)

We observed early shutdowns in large/high-concurrency runs even when early shutdown was configured as disabled. The logged summaries looked like this (example):

• failure_threshold: 1.0
• completed_count: 256
• error_count: 26 (~10% error rate)
• early_shutdown: true

At first glance, a ~10% error rate should not trip a 1.0 threshold. The missing detail was that the early-shutdown decision is latched and depends on the order of task completion, not the final aggregate rate.

Why disable_early_shutdown=True could still early-shutdown

Prior behavior:

• disable_early_shutdown=True normalized shutdown_error_rate to 1.0.
• ConcurrentThreadExecutor still ran the early-shutdown state machine and used error_rate >= failure_threshold.
• Under concurrency, fast failures can complete before slower successes. Once the shutdown window is active, it only takes a moment where error_count / completed_count == 1.0 (e.g., the first N completed tasks are all failures) to set early_shutdown=true.
• That flag is never cleared, so the executor can ultimately exit with a final summary showing a much lower error rate while still raising/marking early shutdown.

In other words, "disable" was implemented indirectly via a numeric threshold, but the mechanism was still active and could still trigger in edge cases (especially in large/high-parallel workloads).

Why this fix

We want a principled contract:

If the user disables early shutdown, the system must not early-stop or raise an early-shutdown error, regardless of thresholds/windows/concurrency timing.

This PR stops relying on indirect numeric behavior and adds an explicit, end-to-end switch that bypasses all early-shutdown decisions.

What changed

• Added an explicit disable_early_shutdown parameter to ConcurrentThreadExecutor.
• When disable_early_shutdown=True, the executor:
  • continues to record errors via ErrorTrap (so users still get accurate summaries),
  • but never sets results.early_shutdown, never triggers shutdown, and never raises the early-shutdown DataDesignerRuntimeError.
• Plumbed RunConfig.disable_early_shutdown through the engine call sites that construct the executor (column-wise threaded fanout + validation parallelism).
• Updated and added tests to lock in the behavior, including a case that would otherwise deterministically early-shutdown (0% threshold, 0 window, 100% failures) and verifying it does not raise when disabled.

Testing

• uv run pytest -q

All tests pass locally.