feat(scheduler): replace clone concurrency limit with cost-based admission

[worstell]

Summary

Replace the binary isCloneJob/MaxCloneConcurrency mechanism with a generic cost model. Strategies declare the cost of each job at submit time, and the scheduler tracks total active cost against a configurable budget (max-cost).

Design

The Submit and SubmitPeriodicJob interface methods now accept a cost int parameter. The scheduler admits a job only when activeCost + job.cost <= maxCost (with a safety valve: any job is admitted when nothing else is running, preventing permanent starvation from misconfiguration).

This removes isCloneJob — the scheduler no longer has knowledge of git-specific job types.

Cost constants (git strategy)

Job type	Cost	Rationale
clone	4	Heavy CPU/IO/network, minutes
snapshot	3	Heavy CPU (zstd), moderate IO
repack	2	Heavy CPU, no network
fetch	1	Lightweight, seconds

Configuration

scheduler {
  max-cost = 16  # default: concurrency * 4
}

With the defaults (concurrency=4, max-cost=16), you can run up to 4 clones, or 1 clone + 3 snapshots + 1 fetch, etc. The worker count remains the hard parallelism cap.

Breaking changes

• max-clone-concurrency config replaced by max-cost
• Scheduler.Submit and SubmitPeriodicJob signatures changed (added cost int)

[alecthomas]

I like this as a general scheduling improvement, but is this going to work as a replacement for the existing MaxCloneConcurrency? I feel like they're solving slightly different problems.