waza run --workers 6 on a suite of 3 tasks + 3 trigger tests only ever runs 3 concurrent sessions because tasks and triggers are executed in serial phases, each with its own worker semaphore. The issue asked for research and recommendations; this PR adds the design doc and ships Phase 1 of the plan (R2 + R3).

Adds docs/design/135-improve-concurrency.md (following the existing docs/design/ convention) capturing the diagnosis and a phased proposal, including a §8 "Critique resolutions" section that addresses the B1/B2/B3 review feedback.

Diagnosis

• Phase barrier in cmd/waza/cmd_run.go: runner.RunBenchmark fully drains before trigger.Runner.RunDetailed starts. Each phase has its own semaphore sized at Workers, so Workers > items_per_phase is unused capacity.
• Per-call Copilot clients in graders: internal/graders/prompt_grader.go (gradeIndependent, runPairwiseOnce) calls copilot.NewClient(...) + client.Stop() every invocation, spawning/tearing down the embedded Copilot CLI subprocess each time. The engine itself already shares one client; graders don't.
• Engine instance is already shared between the task runner and trigger runner and is mutex-protected, so no concurrency-safety blocker for unification.

Recommendations (prioritized)

• R1 — Unified worker pool spanning task + trigger jobs. Introduce a Job interface, build the pool once in cmd_run.go, have TestRunner and trigger.Runner expose Plan() []Job, then submit both sets and demux results by Job.Kind(). Fixes the reported 3/6 utilization. Follow-up PR.
• R2 — Process-wide singleton Copilot SDK client (per @richardpark-msft). All per-call state already lives on the session; expose execution.SharedClient(...) behind a sync.Once, switch prompt_grader to it, and drop the per-call Stop(). Removes the dominant local-run latency. Implemented in this PR.
• R3 — Auto-size --workers default to min(NumCPU, totalJobs, 8) (currently hard-coded 4) and log a one-line "capped to N (phase)" notice. Implemented in this PR. The conservative DefaultWorkerCap = 8 ceiling addresses B1 from the design review until R4 lands.
• R4 (stretch) — Split --workers (job concurrency) from --sessions (Copilot session concurrency) as a second semaphore inside the pool. Defer until the single knob proves insufficient.

Implementation in this PR

R2 — shared Copilot SDK client

• New internal/execution/sdkclient.go exposing SharedClient(opts) CopilotClient and ShutdownSharedClient(ctx) error, both guarded by sync.Once.
• CopilotEngine now defaults to the shared client and tracks an ownsClient flag; Shutdown only calls client.Stop() for engines that own their client (test path). The shared SDK process is stopped exactly once via a top-level defer execution.ShutdownSharedClient(...) in cmd_run.go::runCommandE, so it survives the per---model engine loop.
• CopilotEngine exposes CopilotClient() so the runner can plumb the shared client to graders.
• graders.Context gains a CopilotClient execution.CopilotClient field. TestRunner.buildGraderContext populates it via an interface assertion against the engine.
• prompt_grader.gradeIndependent and runPairwiseOnce use a new shared openGradingSession helper that prefers Context.CopilotClient when set (no Start/Stop overhead, session is Disconnect'd on cleanup) and falls back to the legacy per-call copilot.NewClient(...)/Stop() path otherwise so direct grader tests (prompt_grader_test.go) keep working.

R3 — auto-sized workers

• New internal/orchestration/workers.go with ResolveWorkers(requested, jobs, phase, out) int and DefaultWorkerCap = 8.
• When --workers is unset: defaults to min(runtime.NumCPU(), jobs, 8).
• When --workers exceeds the job count: clamps and emits workers=N capped to M (phase).
• Wired into TestRunner.runConcurrent and trigger.Runner.RunDetailed. The CLI's "Parallel:" line now prints workers=auto when the auto-default applies.

Design doc updates

• §8 "Critique resolutions" addressing B1 (cap), B2 (DI path = Context.CopilotClient), B3 (process-wide singleton lifecycle decoupled from per-engine Shutdown), N4 (use symbol names), and S3 (revised order to R3 → R2 → R1 → R4).

Tests

• internal/execution/sdkclient_test.go — SharedClient returns the same instance, ShutdownSharedClient is idempotent and safe when no client was constructed.
• internal/orchestration/workers_test.go — auto-sizing respects the cap, explicit values are clamped to job count and emit a notice, no notice when within budget.
• Race-enabled tests pass for internal/execution, internal/orchestration, internal/trigger, internal/graders, and cmd/waza.

Open questions for reviewers

1. Prefer Job interface in internal/orchestration, or keep packages self-contained and have Plan() return work descriptors that the CLI hands to a thin pool? (R1 follow-up)
2. @richardpark-msft — confirm the SDK is safe sharing one Client across N concurrent CreateSession calls without per-call Start/Stop. The implementation now relies on this.
3. R4 now or later? Default cap of 8 is in place as a holdover.