Concurrency cap step-down as usage lever (3 to 2 to 1 to pause)

[Ryan-Atkinson87]

Step the wave concurrency cap down as the governing meter climbs, gliding into the hard pause
instead of hitting a wall.

Spec: §18.7 (Concurrency cap as a usage lever), §18.8 (Interaction summary).

Acceptance criteria

• As the governing meter (Threshold evaluation and date-sensitive Agent SDK credit meter handling #33) climbs toward the threshold, step the cap down through the scheduler's cap-step-down hook (Wave concurrency scheduler (parallel-across-repos, serialised merge queue, configurable cap) #25): 3 → 2 → 1 → pause. The exact climb points are deterministic and documented in code.
• The hard pause (Hard pause and two-tier automatic resume (reset-known sleep + backoff probe) #34) remains the floor; cap-stepping is a smoothing layer above it. At the floor there is at most one in-flight session, so the pause drains cleanly.
• Driven by the same ~5-min usage poll as the threshold check (§15 resolution direction); no separate, faster polling loop.
• Stepping the cap never starts new sessions beyond the current cap; it only lowers the ceiling for the next scheduling decision.
• Bounds the crash-recovery evaluation set: with the cap and per-repo sequential work, at most N issues are ever in flight (§18.8).
• Unit tests cover the step sequence as the meter climbs, the hand-off to hard pause at the floor, and that stepping down does not interrupt an already-running session mid-step.

Depends on: #30
Depends on: #25
Depends on: #34