Add per-model cloud rate scheduling and task manifests

[laceyp99]

Summary

• Add validated per-model RPM pacing with configurable per-model and global cloud concurrency limits.
• Use Core's provider_call progress event as the dispatch boundary and durably journal dispatched before allowing a provider request to continue.
• Record task setup and validation errors before that boundary as pre_dispatch_failed; these tasks do not advance the model RPM clock or stop the remaining model queue.
• Stop queued work after typed provider throttling while allowing already-dispatched work and other model queues to finish.
• Persist atomic task manifests and an append-only transition journal with expanded summary counters for completed, failed, pre-dispatch-failed, throttled, and unstarted tasks.
• Document scheduling, dispatch durability, manifest artifacts, and failure behavior, with expanded evaluator and analysis regression coverage.

close #10

Testing

• uv sync --locked --all-extras - passed
• uv run --locked --all-extras ruff format --check . - 16 files already formatted
• uv run --locked --all-extras ruff check . - passed
• uv run --locked --all-extras pytest -q - 162 passed
• uv build - passed

[laceyp99]

Closing this in favor of #27 after comparing the two approaches holistically.

This PR implements genuine per-model RPM pacing, but doing so also introduces a substantial scheduling and durability subsystem into Eval: dispatch acknowledgements, multiple concurrency layers, task manifests, an append-only transition journal, queue cancellation, and recovery-oriented state transitions. That machinery is defensible for production-grade quota scheduling, but it is disproportionate for this personal evaluator and materially increases the surface area we would need to maintain and trust.

#27 makes the narrower architectural choice explicit: Eval owns a configurable per-provider concurrency cap and records typed provider throttling as a distinct result, but it does not claim to enforce RPM, TPM, or RPD quotas. For the expected supervised workloads, that is the preferred tradeoff. If strict quota scheduling becomes necessary later, it should be implemented once in conductor-core at the provider dispatch boundary rather than as Eval-specific orchestration.

This closure is therefore a scope and maintainability decision, not a judgment that the implementation here lacks rigor.