fix(scheduler): wire mem reservation reconciliation into live rusage event path

sched_reconcile_job_resource_usage() was only reachable from
sched_apply_job_rusage() (scheduler.c's sched_update(), which has no live
caller), so real-usage reconciliation never actually ran outside tests.
Wire it into core_events.c's XCE_CORE_EVENT_JOB_RUSAGE handler instead,
the actual live path shared by both normal-mode (driver.c) and sim/replay
mode (sim_loop.c). Adds link-satisfying stubs to the testsuite files that
#include core_events.c directly.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y4M5MJM2zK6nU43da267Ku

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

@@ -1,6 +1,6 @@
 # Implementation Plan
 
-- [ ] 1. Foundation: controller-side dispatch-failure classification and durable transition record
+- [x] 1. Foundation: controller-side dispatch-failure classification and durable transition record
 - [x] 1.1 (P) Define the dispatch-failure classification used to decide whether a failed dispatch attempt should retry or fail permanently
   - Enumerate each distinct way a dispatch attempt to a worker can fail today (worker lookup, worker unavailable, worker not ready, invalid allocation, queue configuration lookup, the dispatch request itself failing), and classify each as either retryable (transient/environmental) or terminal (a locally invalid decision that retrying will not fix)
   - The classification is a pure decision with no side effects, independently testable against every known failure case without needing a live dispatch attempt
@@ -22,7 +22,7 @@
   - _Requirements: 4.3_
   - _Boundary: Controller Dispatch-Failure Classification (retry-counter data model)_
 
-- [ ] 2. Core: scheduler transitions a job to running state at dispatch-commit time
+- [x] 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.
 - [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
@@ -38,7 +38,7 @@
   - _Requirements: 3.1, 3.2, 4.4_
   - _Boundary: Scheduler Dispatch-Failure Handler_
 
-- [ ] 3. Core: controller transitions a job to running state only once dispatch to the worker succeeds, and resolves failures
+- [x] 3. Core: controller transitions a job to running state only once dispatch to the worker succeeds, and resolves failures
   - Sub-tasks 3.1-3.3 all restructure the same function and share its per-job lock scope, so none of them are marked parallel to each other, regardless of how disjoint their individual concerns look.
 - [x] 3.1 Controller commits a job's resource allocation and running-state transition together, only on a successful dispatch
   - The controller's existing (currently unconditional) commit of a job's resource-allocation data becomes conditional on the dispatch request to the worker actually succeeding; the job's state transition to running happens in that same successful outcome, protected against concurrent access to the job record
@@ -63,14 +63,14 @@
   - _Requirements: 4.1, 4.3, 4.4, 4.5_
   - _Depends: 1.1, 1.3, 3.2_
 
-- [ ] 4. Integration: caller no longer duplicates dispatch-outcome reporting
+- [x] 4. Integration: caller no longer duplicates dispatch-outcome reporting
 - [x] 4.1 Remove the caller's own dispatch-outcome reporting now that resolution owns it
   - The function that invokes a dispatch attempt for each job in a batch no longer separately reports the outcome itself — reporting is now entirely owned by the dispatch resolution added in Task 3, preventing a failed dispatch from ever producing two different, conflicting outcome reports for the same job
   - Observable completion: a dispatch failure that resolves as permanent produces exactly one outcome report, not two conflicting ones
   - _Requirements: 3.1, 4.1, 4.2_
   - _Depends: 3.1, 3.2, 3.3_
 
-- [ ] 5. Validation: end-to-end behavior and regression
+- [x] 5. Validation: end-to-end behavior and regression
 - [x] 5.1 End-to-end test: resource-in-use accounting survives a multi-round gap between dispatch and confirmation
   - Reproduce bug-1624 directly: dispatch a job, let several rounds pass before the worker confirms it started, and confirm resource-in-use totals reflect the job continuously from the round it was dispatched, matching what a same-round confirmation would have produced
   - Observable completion: the regression scenario passes, and fails against the pre-change code path if temporarily reverted