Wave concurrency scheduler (parallel-across-repos, serialised merge queue, configurable cap)

[Ryan-Atkinson87]

Implement the wave concurrency scheduler: parallel across repos, sequential within each repo, serialised merges, configurable cap (Spec §18.6). Deferred here from Phase 2 because it schedules the per-issue pipeline defined in this phase.

Spec §18.6 (concurrency model), §18.7 (cap as a usage lever — the stepping hook), §18.8 (interaction summary).

Acceptance criteria

• Each repo runs at most one active issue at a time (sequential within a repo); different repos run concurrently (parallel across) — Spec §18.6.
• A configurable cap on total in-flight issues, defaulting to the number of repos in the project (one active issue per repo); a cap of 1 is fully sequential (§18.6).
• A serialised merge queue: review sessions may run concurrently, but merging a feature branch into the agent branch is one-at-a-time per repo, eliminating merge races (§18.6).
• Cross-repo dependencies are respected by not starting a dependent issue until its dependency reaches a stable done state — parallelism across repos does not violate dependency ordering (§18.6); relies on the engine's dependency ordering (GitHub issue/milestone reader and dependency-order wave assembly #26).
• A hook to step the cap down (3 → 2 → 1 → pause) is exposed for the usage monitor to drive in Phase 4 (§18.7); the hook exists now, the usage logic that calls it is Phase 4. The hard pause remains the floor.
• The cap bounds the crash-recovery evaluation set (§18.8) — at most N issues in flight, so paired with Per-issue state markers and resume-or-reset crash recovery #24 at most N issues need resume-or-reset.
• Built on asyncio (Spec §13 stack) — a single async process with parallel sessions, consistent with the SQLite-not-Postgres decision (§15 Postgres-switch open item).
• Tests: two repos run concurrently while one repo serialises two issues; cap of 1 forces full sequencing; the merge queue serialises two ready merges; cap-step-down hook reduces in-flight admission.

Notes

The usage monitor (Phase 4) drives the step-down; this issue only provides the lever and the default cap behaviour.

Depends on: #11, #4