fix(scheduler): make concurrency cap atomic with claim_execution

[pratyush618]

Summary

The pre-release audit (P0-1, see .claude/reports/codebase-prerelease-2026-05-02.md) flagged a TOCTOU race on the per-task / per-queue concurrency gates. Investigating the surrounding code surfaced a second, distinct bug that was hiding in the same lines: an off-by-one that made max_concurrent = N allow only N-1 jobs (and max_concurrent = 1 allow none).

Both bugs are fixed in this PR.

What was wrong

1. Race: the cap check ran before claim_execution. Two scheduler instances could each read a running count below the cap and both proceed past the gate before either recorded the new running job. SQLite was masked by transaction serialization; Postgres (SELECT FOR UPDATE SKIP LOCKED) and Redis were fully exposed.

2. Off-by-one: dequeue_from atomically transitions status Pending → Running before the cap check runs, so count_running_by_task / stats_by_queue.running include the just-dequeued job. The >= comparison therefore counted the current job against itself.

What changed

• try_dispatch is split into named helpers — active_queues, check_pre_claim_gates, claim_for_dispatch, check_post_claim_concurrency, rollback_claim_and_retry. Each step of the dispatch flow is now self-documenting and individually testable.
• The concurrency cap check moved to after claim_execution succeeds, comparing with strict >. Two concurrent schedulers cannot now both pass the gate when capacity is full — at most one will see the count at-cap and proceed; the other observes count > cap and rolls back.
• New rollback path: when the post-claim gate rejects a job, complete_execution clears the claim row before retry resets status. Without this, the next dispatch attempt would hit claim_execution → Ok(false) ("already claimed") and the job would be stuck until the claim was reaped on timeout.
• Pre-claim gates (rate limiter, circuit breaker) keep their existing position — they don't need atomic-with-claim semantics, and consuming a token / probing the breaker post-claim would waste them on rolled-back claims.

Tests

Three new regression tests in crates/taskito-core/src/scheduler/mod.rs:

• test_try_dispatch_per_task_concurrency_allows_exactly_max — enqueue 3 jobs with max_concurrent = 2, verify exactly 2 dispatched and the third is back in Pending with no stale claim row.
• test_try_dispatch_per_task_max_one_dispatches_one — direct regression for the off-by-one.
• test_try_dispatch_per_queue_concurrency_allows_exactly_max — same shape on the queue-level cap.

Test plan

• cargo test --workspace — all 78 tests pass + 3 new
• cargo clippy --workspace --all-targets -- -D warnings clean
• cargo check --workspace --features postgres clean
• cargo check --workspace --features redis clean
• uv run python -m pytest tests/python/ — 485 passed, 9 skipped
• uv run ruff check py_src/ tests/ clean
• uv run mypy py_src/taskito/ clean
• CI green