feat(scheduler-dispatch-commit): scheduler transitions job to RUN at dispatch commit (task 2.1)

sched_commit_decision()'s DISPATCH branch now sets job->state = JOB_STAT_RUN
in the same operation that already commits job->allocs/job->accounts, per
Requirement 1.1/1.2/1.3. sched_account_jobs()'s existing JOB_IS_RUN gate is
unmodified -- this closes bug-1624 by giving it the input it was missing: a
dispatched job now survives a round boundary in resource-in-use totals
regardless of how many rounds pass before worker confirmation arrives.

Regression test drives the real, unmodified sched_account_jobs() across a
simulated round boundary (resInUse reset, no confirmation event) and
independently reverting the one-line change reproduces bug-1624 exactly.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

.kiro/specs/scheduler-dispatch-commit/tasks.md

@@ -24,7 +24,7 @@
 
 - [ ] 2. Core: scheduler transitions a job to running state at dispatch-commit time
   - No dependency on Task 1 — scheduler-side files only, independent of the controller-side foundation work above.
-- [ ] 2.1 (P) Scheduler marks a job as running in the same operation that commits its dispatch decision
+- [x] 2.1 (P) Scheduler marks a job as running in the same operation that commits its dispatch decision
   - When the scheduler commits a decision to dispatch a job, the job's state becomes running immediately, in the same operation that already records the job's resource allocation — not waiting for any later confirmation
   - The scheduler's existing resource-in-use accounting, which only counts jobs already in a running state, requires no changes — this task provides the input it was missing
   - Observable completion: a job dispatched in one round appears in resource-in-use totals starting that same round, and continues to appear in every subsequent round regardless of how many rounds pass before any confirmation arrives